What to tell your customers while your app is down

Your app is down. You know because someone told you, or because you opened it yourself and got a blank screen. You have twelve tabs open and you're about to open a thirteenth.

Here's the uncomfortable truth: your users will forgive the outage. Almost every one of them. What they won't forgive is the twenty minutes where they sat refreshing, wondering if their data was gone, wondering if you'd noticed, wondering if you were a real business.

Atlassian, who make one of the most widely used status tools on the internet, put it plainly after surveying their own customers in 2018 — people expect the occasional hiccup, and what they won't tolerate is being left in the dark.⁶ Nothing about that has changed since.

Should I wait until I know what broke?

No. You do not need to know what broke to tell people it's broken. If you wait until you understand the cause, you'll be silent for exactly the window in which silence does the damage.

Supabase — the database a huge number of AI-built apps sit on top of — had a bad one on 12 February 2026. Everything in their Ohio region went down for three hours and forty-two minutes. Their write-up afterwards is unusually honest: customers noticed and reported the issue before Supabase posted anything publicly. They called their own communication insufficient and at times misleading, and too slow at the start.¹

Not too slow to fix it. Too slow to say it. That's a company with a serious engineering team and a real status page. You are one person with a laptop, so your version of this failure is much easier to fall into.

Some of you are seeing errors on [app name] right now.
It's on our side, we're on it, and I'll post an update
here by [specific time]. Your data is safe.

Notice what it doesn't contain. No cause. No fix. No apology paragraph. No "we take reliability extremely seriously." Only include the last line if you actually believe it — otherwise say "I'm checking whether anything was lost and I'll tell you straight either way." That sentence buys enormous credit and costs you nothing.

Should I tell people when it'll be fixed?

Never give a fix time. Give an update time. This is the rule people break first, because a stressed founder desperately wants to hand out good news.

"Should be back in ten minutes" is a promise you cannot keep, and when minute eleven passes you've converted a technical problem into a trust problem. Now you're not the person whose app broke. You're the person who said ten minutes.

"I'll update you by 3:30 whether or not it's fixed" is a promise you can keep with certainty, because keeping it requires only that you type. Supabase's own conclusion was that they should have updated more frequently and with more context, and posted even when they had no new technical findings.¹ "Still working on it, no news yet, next update at 4:00" is not a failure. It's proof someone is awake.

Pick a rhythm and hold it. Every thirty minutes is generous for a small app. Every hour is fine once it's dragged on. What kills you is the gap where people conclude you've gone to bed.

How specific should I be about what's broken?

Specific. "The app is down" is often not true, and users can tell. Usually sign-up is broken but existing sessions are fine, or payments fail while browsing works.

PagerDuty's guidance on status communication makes a small point that matters a lot here: name the parts of your app the way your customers name them.⁴ "Dashboard" and "Login," not the internal names your AI tool generated. Your users have never heard of your edge function. They know they can't get in.

If your database provider or host fell over rather than your code, you can say so — as information, not as a shield. "Not our fault" is not a sentence that helps anyone. It's still your app on their screen.

And sometimes it isn't an outage you control at all. Cloudflare's summary of internet disruptions between April and June 2026 describes what these events feel like from outside — pages failing to load, email bouncing, apps timing out — caused by a fibre cut or a storm thousands of miles away.³ Spend sixty seconds checking whether it's just you. No more.

Where should I post the update?

Wherever your users already are, not where you wish they were. Email if they live in email, Discord or WhatsApp if that's the group, and an auto-reply on your support inbox saying the same three sentences, because that's where the panic lands first.

A single line of text at the top of the app itself is the best place of all, and the one everyone forgets. Supabase forgot exactly this: their post-mortem notes the banner inside their own dashboard never appeared during the February outage, because of a change made earlier that week to reduce noise.¹ The status page was updating. The people staring at the broken screen saw nothing.

If you build one thing after reading this, build the banner. A hardcoded one you switch on manually is completely fine. Then make it one place and point everything else at it — PagerDuty's framing is that a single source of truth during an incident calms people down and stops your inbox filling up.⁴

Add a site-wide notice banner to my app. It should render a single line of text at the very top of every page, above all other content, and be controlled by one boolean plus one message string that I can edit in a single config file. Make it visually obvious (coloured background, readable on mobile), dismissible per session, and default to off. Don't fetch the state from an API — I need it to work even when my backend is down.

What should I not say?

Nothing is the worst option, and it's always available, which is why people pick it. After that, the biggest mistakes are jargon and false hope.

• "Intermittent issues with elevated error rates." Nobody outside the industry knows what that means, and everybody inside it knows it means "it's down."
• A long apology in the first message. Grovelling reads as panic. Apologise once, at the end, when you know what happened.
• The full technical story. One line of cause is plenty: "a database change I made yesterday broke logins." More than that and you're processing your own stress at your users.
• Blaming someone's browser or connection without evidence. Tell a person in a real outage to clear their cache and they will remember it.

What do I send after it comes back?

Say it came back — explicitly, in the same place, in the same voice. Then within a day send one short note: what broke in plain words, how long it lasted, whether anything was lost, what you changed.

Cloudflare's write-up of their own six-hour-and-seven-minute outage on 20 February 2026 opens, before any technical detail, with an apology and the words "We let you down today."² Six words. That's the register. You don't need to be more elaborate than a company with thousands of engineers.

Say the duration as a number. Blurring it is exactly what makes people suspicious. OneUptime made this argument well in March 2026: nobody expects perfection, everyone expects honesty, and a handful of honestly reported incidents signals a company with its act together far more than a suspiciously clean record.⁵

Then do the boring cleanup, because this is where you win people back. Find the users who tried something during the window and couldn't — the failed sign-up, the double payment, the vanished order. Contact them individually and fix their specific thing. That's ten emails, and it turns your worst day into the reason someone tells a friend about you.

What should I do today, while nothing is wrong?

1. 1
   Write the first message

   Three sentences with your app's name already filled in, and a blank for the update time.
2. 2
   Write the holding update

   "Still working on it, no news yet, next update at ___." You'll send this more than once.
3. 3
   Write the all-clear

   One line saying it's back, posted in the same place as the first message.
4. 4
   Write the next-day note

   A paragraph with blanks for the cause and the exact duration. Short apology at the top.
5. 5
   Build the banner

   One line of text at the top of your app that you can switch on by hand, without your backend being alive.

Twenty minutes of work on a calm afternoon. Because when it happens you will not be calm, and writing well while frightened is a skill almost nobody has.

Open a note now and write the four messages. That's the whole task. The outage your users describe afterwards as "handled well" is entirely available to you — it just isn't available at 2am, invented from scratch, with your hands shaking.