AperioFlow Start free

Blog

How to write an incident update: a plain template for small teams

Why customers forgive downtime more readily than silence

Most customers can accept that a site breaks. What they do not accept is finding out from someone else, or waiting an hour with no word from you. When a checkout fails and the status page still says everything is working, people assume you do not know, or do not care.

A short, honest update fixes most of that. It tells people you are aware of the problem, that you are working on it, and when they will hear from you next. You do not need to know the cause to post one.

The four statuses to use: investigating, identified, monitoring, resolved

Keep to four statuses. Each one tells the reader where you are.

  • Investigating. You have seen a problem and are looking into it. You may not know the cause yet.
  • Identified. You know what is wrong, or roughly where. Say so, and leave out detail you have not confirmed.
  • Monitoring. A fix or change is in place. You are watching to see that it holds.
  • Resolved. The service works as it should again. Say when it recovered.

Use the same words every time. Customers learn the sequence quickly, and they stop worrying once they see the update move forward.

What each update must say: what is affected, what you know, what you are doing, when the next update is due

Every update answers four questions, in this order.

  1. What is affected? Name the feature, page or service. 'Customer log-in is failing' is useful. 'Some users may experience issues' is not.
  2. What do you know? Give facts only: times, error types, and who is hit.
  3. What are you doing? One or two actions. 'We have rolled back the latest release' is clear.
  4. When is the next update due? Give a time, even if the answer is 'no change yet, next update by 14:30'. Then keep to it.

The last point is the one small teams miss most often. If you promise an update at 14:30, post one at 14:30, even if nothing has changed. A quiet promise kept builds more trust than a long explanation.

A template you can copy for each status

Copy the lines below, fill the gaps and post.

Investigating

[Date and time, with time zone]. We are investigating reports that [what is affected]. We do not yet know the cause. Next update by [time].

Identified

[Date and time]. We have found the cause of the problem with [what is affected]: [one plain sentence]. We are [action]. Next update by [time].

Monitoring

[Date and time]. A fix for [what is affected] is in place. We are watching [what you measure] to confirm it holds. Next update by [time].

Resolved

[Date and time]. [What is affected] has recovered as of [time]. Cause: [one sentence]. [Follow-up step, if there is one.] Thank you for your patience.

A worked example in short sentences with concrete nouns

Imagine a small agency running a booking site for a client. Here is how the four updates might read on one afternoon.

Investigating, 14 March 2025, 09:12 GMT. Booking pages return an error when a customer picks a date. We are looking into it. We do not know the cause yet. Next update by 09:45 GMT.

Identified, 14 March 2025, 09:38 GMT. The booking database hit its connection limit after a batch import. We are cutting the import into smaller batches and restarting the booking service. Next update by 10:00 GMT.

Monitoring, 14 March 2025, 09:56 GMT. Booking pages load and accept dates again. We are watching error rates for 30 minutes. Next update by 10:30 GMT.

Resolved, 14 March 2025, 10:24 GMT. Booking has been stable since 09:50 GMT. Cause: the import ran at the same time as peak bookings. Imports will now run at 02:00 GMT.

Notice what is missing. There is no apology spiral, no guess about the hosting provider, and no list of internal tools. A customer can read it in twenty seconds and know what to do.

What to leave out: guesses, blame and jargon

Leave out guesses. 'It is probably the network' can be wrong, and it will be quoted back to you later. If you do not know, say you do not know, and give the next update time.

Leave out blame. Naming a supplier or a team member makes the update about your internal problems, and customers rarely care whose fault it was. If the cause involves a third party, describe what happened to the service instead.

Leave out jargon. Words like 'root cause', 'failover' or 'pod restart' mean something to you and nothing to a customer who only wants to book a table. Use the words the customer uses: the booking page, the log-in, the checkout.

A scheduled maintenance notice example, and how it differs from an incident update

A maintenance notice is planned. You choose the window, and customers can work around it. An incident update responds to something that has gone wrong, and it has no fixed end time when you post it.

Here is a short maintenance notice.

Scheduled maintenance, 21 March 2025, 22:00 to 23:00 GMT. We are upgrading the payment library used by the online shop. Checkout will be unavailable during this window. Orders placed before 22:00 GMT are not affected. We will post here when maintenance is complete.

The differences are practical. A maintenance notice gives a start and end time and says what will stop working. It is posted before the work begins, not during it. It has no investigating or identified stage, because nothing has broken. An incident update, by contrast, needs the status sequence and a next update time, because you cannot yet say when it will end.

How to publish updates on an AperioFlow status page so customers see the same message everywhere

The quickest way to keep messages consistent is to write each update once and post that exact wording on your status page and in any message you send to customers. Use the four statuses above so the sequence looks the same wherever a customer reads it.

An AperioFlow status page lets you post incident updates and scheduled maintenance notices in one place. Your monitors can show when a site or cron job is failing, which helps you start the first update sooner. Your data is hosted in France and the service is run from the UK, and you can download your data at any time. Alert emails go only to people in your organisation.

Set the page up before you need it. You will be writing under pressure when something breaks, and a template you have already tried is much easier to use at 09:12 on a bad morning.

Start free at https://app.aperioflow.co.uk/#/signup. The free plan includes 10 monitors. If your team grows, Team is 29 pounds a month flat for up to 10 people, as on the pricing page.

Start free More from the blog

Built for the people who write the code and answer the phone when it breaks.

Run from the UK. Hosted in France.

UK time --:--

Already in?Open the app Start free today
View our policies