---
title: "The client email you have to send when their site went down"
description: "What to write to a client when their site goes down: four sentences, sent immediately, plus the follow-up and the write-up afterwards."
url: https://www.fomio.ai/blog/the-client-email-you-have-to-send-when-their-site-went-down
published: 2026-09-24T18:00:00.341+00:00
updated: 2026-09-24T18:00:00.341+00:00
topic: consequence
words: 1871
---

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

Four sentences, sent in ninety seconds, will do more for you than a perfect explanation sent at 4pm.

**In short:**

- Send a short message immediately, before you understand the cause.
- Promise an update time, never a fix time — you control one and not the other.
- Give your client one sentence they can repeat to their own customers.
- Write the wording now, while nothing is broken, and keep it in a note.
- The question that decides whether you keep the client is how long it was broken before you knew.

### What do I tell a client whose site went down?

Send four sentences straight away: what is broken in words they would use, who it affects and since when, that you are working on it now, and exactly when you will write again. Do not guess at the cause and do not promise a fix time. Promise an update time instead.

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. What's broken, in the words your client would use. Not "the database connection is failing" — "the booking form isn't saving bookings."
2. Who it affects and since when. "Anyone who tried to book since about 9:40 this morning."
3. What you're doing right now. "I'm on it. I know where the problem is."
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.[^1]

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?

*The first email, filled in.*

```
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.[^2] That second half is the whole value of the email.

> **Keep the templates where you'll find them** — Three saved drafts — first alert, no-news update, write-up — take ten minutes to write today and save you the worst twenty minutes of a bad afternoon.

## 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.

*Fomio's three plans, since you may be quoting these promises to a client.*

| Plan | Apps watched | How often it checks | What you get |
| --- | --- | --- | --- |
| Free | 1 | Every 5 minutes | Email alerts, 7 days of history, no card needed |
| Builder | 3 | Every minute | Fix prompts for your AI tool, 30 days of history |
| Pro | 15 | Every minute | Public status page for your client's users, 1 year of history |

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](https://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.

**Paste this into your AI tool**

```text
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. **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. **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. **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. **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. **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.

## Questions people also ask


### Should I tell the client the cause if I'm fairly sure I know it?

Not in the first email. "Fairly sure" becomes "wrong" often enough that the cost of guessing outweighs the small credibility you gain from sounding informed. Say you've found where it's going wrong and you're fixing it — that's true and it commits you to nothing. Put the cause in the final write-up, when you actually know it, in one plain sentence. A single confident explanation later beats two contradicting ones today.

### How often should I send updates during an outage?

Pick an interval you can actually keep and state it in every email. An hour or ninety minutes works for most small projects. The important part is that the client never has to chase you, which means sending the update even when nothing has changed. "Still on it, nothing new, next update at 1" takes fifteen seconds and does the entire job. Missing a promised update does more damage than the outage itself.

### What if the site came back before I noticed and the client already saw it?

Still send the write-up, and be plain that they spotted it first. Trying to imply you were already on it is a risk with no upside. Say what was broken, say it's working now, say what you're changing so you find out before they do next time. Then actually make that change today — the credibility comes from the change, not the email describing it.

### Do I need a public status page for a small client site?

Only if your client's own users contact them directly. If a broken page produces eleven forwarded "is it down?" emails, a page you can point people at saves everyone the loop. For a brochure site with light traffic, four good emails to one person is plenty. Fomio includes a public page on its Pro plan; plenty of other tools offer them too, so it's worth checking what you already pay for.

### How do I write the "what's different now" line without over-promising?

Describe one specific, small change you have already made, not an intention. "I've set up something that checks the booking form every minute and emails me if it stops working" is concrete and verifiable. "I'll be monitoring things more closely" is not, and your client can tell. One real change lands better than three vague commitments, and it means the next outage starts with your email rather than theirs.


## Sources

[^1]: Incident communication best practices — Atlassian (2026-06-09). https://www.atlassian.com/incident-management/incident-communication
[^2]: Incident communication templates and examples — Atlassian (2026-06-09). https://www.atlassian.com/incident-management/incident-communication/templates
[^3]: Create, manage, and communicate incidents — Atlassian Support (Statuspage). https://support.atlassian.com/statuspage/docs/create-manage-and-communicate-incidents/