The client email you have to send when their site went down

Your client's site is down. Maybe it's back already. Maybe it isn't. Either way there's a message sitting in your drafts that you've rewritten four times, and every version sounds either like a confession or like you're hiding something.

1. 1.What's broken, in the words your client would use. Not "the database connection is failing" — "the booking form isn't saving bookings."
2. 2.Who it affects and since when. "Anyone who tried to book since about 9:40 this morning."
3. 3.What you're doing right now. "I'm on it. I know where the problem is."
4. 4.When you'll write again. "I'll update you by 11, whether or not it's fixed."

That's the whole email. You can send it in ninety seconds and it will do more for you than a flawless explanation that arrives six hours late.

Why does the fast, half-informed email beat the good one?

Because your client is not sitting calmly waiting for your analysis. They're watching their own customers hit a broken page, and the only thing worse than a broken page is a broken page plus silence from the person who built it.

Silence gets filled in. Usually with something worse than the truth. Waiting until you can explain the cause feels more professional and isn't.

Atlassian's guidance on telling people about an outage — written for large software teams, but the principle holds at any size — treats getting the message out as something you do during the problem, not after it. It also recommends keeping prepared wording ready, because sitting down to a blank page mid-problem is much harder than it sounds.¹

That's the bit worth stealing. Not the tooling — the habit of having the words already written. Write them once, now, while nothing is on fire, and keep them in a note. You will use them more than once.

What does the email actually look like?

Subject: Booking form is down — I'm on it

Hi Sam,

The booking form on the site stopped saving bookings at around 9:40 this morning. Anyone who tried since then will have seen an error. Nothing that was already booked is affected.

I've found where it's going wrong and I'm fixing it now. I'll email you again by 11 with either "fixed" or "still working on it" — you won't have to chase me.

If anyone contacts you about it, you can tell them we know and it's being worked on today.

— Alex

Notice what's not in there. No cause. No apology paragraph. No promise about when it'll be fixed. You don't know any of those things yet, and inventing them is how you end up sending a second email that contradicts the first.

Notice what is in there: the last line. Give your client something to say to their own people. They are going to be asked. If you don't hand them a sentence, they'll make one up, and it'll be vaguer and more worrying than yours.

What makes this email go badly?

• Guessing at the cause. "Looks like the host had a wobble." If you're wrong, and you often will be, you have to walk it back — and the walk-back is what makes a client stop trusting you. "I know where it is and I'm on it" is true and commits you to nothing.
• Apologising too much, too early. One line of regret is right. Four paragraphs of it reads like something much worse happened than actually did. Save the real apology for the end, when you know the size of what you're apologising for.
• Promising a fix time. Promise an update time instead. You control when you send an email. You do not control when a broken thing becomes an unbroken thing.

What goes in the second email, and the last one?

The second email is the easiest thing you'll write all day, because you already promised it. Send it even if there's no news — especially if there's no news. "Still on it, nothing new to report, next update at 1" is a boring email that quietly tells your client you have not disappeared.

The last email, after it's fixed, is where you get to be good at your job. One sentence on what happened in plain words. One short sentence on what you did. Then one on what's different now — the thing that means you won't be having this conversation again in six weeks.

Atlassian's guidance for the write-up afterwards frames it the same way: tell people what went wrong and what you're doing so it doesn't happen again.² That second half is the whole value of the email.

What will the client actually ask afterwards?

Not "what was the root cause." A day or two later, in a slightly too-casual tone: "how long was it down before you knew?"

That's the question that decides whether you keep the client. If the honest answer is "I knew when you told me," it doesn't matter how good the four emails were.

So the real fix isn't a template. It's making sure you are the one who sends the first message, every time. Opening with "hey, the booking form went down about four minutes ago, I'm on it" changes the relationship. You stop being the person who broke it and become the person who caught it.

What does it take to be the one who finds out first?

Less than you'd think. Something that loads your app the way a real visitor would, every few minutes, and emails you when it stops working properly. That's the whole requirement.

Most tools that do this were built for engineers and read like it. They'll ask you how often to check, what counts as a failure, which numbers in a server's reply mean trouble. If you built the app with Lovable, Replit, Bolt or v0, you didn't choose that stack and shouldn't have to learn its vocabulary to find out your own site is broken.

Fomio is the one we built, so treat this as the disclosure it is. You paste a link, it works out what to watch, and there's nothing to set up. It tells you one of three things about your app — Working, Having trouble, or Down — and for the last two it says in plain language what likely went wrong. On the paid plans it also writes a prompt you can paste straight into the AI tool you built the app with, which is often the difference between "I'm on it" being true and "I'm on it" being hope.

Be clear about the limits. Fomio tells you by email — not text message, not WhatsApp, not a chat app. Current prices are on fomio.ai/pricing. And if what you need is history longer than a year, checks from many countries at once, or a rota that wakes a second person at 3am, there are tools built for exactly that and they'll serve you better.

The booking form on my site stopped saving new bookings. Users see an error when they submit. Find where the save fails, explain in plain language what went wrong, and show me the smallest change that fixes it without touching bookings that already exist.

What should I do in the next ten minutes?

1. 1
   If the site is down right now, send the four sentences

   What's broken in their words, who it affects and since when, that you're working on it, and when you'll write again. Don't explain the cause.
2. 2
   Set the next update time and keep it

   Put it in a timer. Send that email even with nothing to report. The boring update is the one that buys you trust.
3. 3
   When it's back, send the write-up

   One sentence on what happened, one on what you did, one on what's different now so it doesn't happen again.
4. 4
   Save all three as drafts

   Strip the specifics out and keep the skeletons in a note. Next time you're filling in blanks, not writing from scratch.
5. 5
   Set something up to watch the site today

   Before you forget the feeling. The goal is that next time, the first email in the thread is from you.

Your client doesn't need you to be infallible. They need to never be the one who tells you.