Once the site is back up, most small teams stop. The status page says resolved, the customer has replied, and everyone goes back to what they were doing. A few weeks later the same fault returns, and nobody can say whether it was the same problem.
A short review fixes that. It does not need a meeting or a template with twelve sections. It needs a few facts written down while they are still clear, and one change that someone is responsible for.
This post covers what goes in the write-up after the fix. For the messages you send while the incident is still running, see our posts on what to put in an incident update.
Why a short review beats none
If you run a client site, or a product for a handful of users, you are often the only person who knows what broke. When you are also the one who gets the alert, the fix lives in your head. Write it down and two things happen. You stop relying on memory when a client asks what happened, and you get a record you can check against the next fault.
Keep it short. One page is enough. If the review takes longer than the fix did, people will skip it.
What happened, in order, with times
Write the timeline first, before any explanation. List each event with the time it happened, in the time zone you work in:
- 09:12 on 14 March 2025: checkout page began returning 500 errors
- 09:40 on 14 March 2025: customer emailed to say the basket was empty
- 09:52 on 14 March 2025: deploy rolled back
- 10:05 on 14 March 2025: status page updated to resolved
Use full dates in the record, even though it feels repetitive. Six months later, 'Friday' means nothing.
Keep to facts you can check: when a monitor fired, when a deploy went out, when someone logged in. Leave out guesses, or mark them clearly as guesses.
How you found out: monitor, customer or luck
This question tells you the most. Each incident is found in one of three ways:
- A monitor noticed it. Good. Check whether the alert fired fast enough and reached the right person.
- A customer reported it. Work out why no monitor caught it. Was there no check on that page? Did a check exist with the wrong threshold?
- Luck. Someone happened to be looking at the page. Treat this as the most important case, because it will happen again on a quiet day.
Catching errors before users report them is mostly a matter of checking the paths customers actually use, not just the homepage. If checkout failed and only the homepage was watched, the fix is a monitor on checkout, not a longer note about being careful.
Heartbeat monitors matter here too. If the fault was a backup that stopped running, or a scheduled job that quietly did nothing, the question is whether that job sends a heartbeat when it finishes. A heartbeat monitor expects a signal at a set interval and alerts you when the signal does not arrive. Without one, a silent failure can go unnoticed for weeks.
What fixed it
Write one or two sentences on the change that restored service, and one or two on the change that stops it happening again. They are often different. A rollback restores service. A test added to the deploy step stops the repeat.
Be specific. 'Improved error handling' tells the next person nothing. 'Checkout now shows a clear message when the payment provider times out, instead of a blank page' does.
One change to make this week, with an owner
Every review should end with one change, a named owner and a date. Not five actions. Five actions get none done.
Examples of a good single change:
- Add a monitor on the checkout page, with an alert to the person on call. Owner: Sam. Due: 21 March 2025.
- Add a heartbeat to the nightly backup script. Owner: Priya. Due: 20 March 2025.
Put the change where it will be seen. A follow-up in a document nobody opens is the same as no follow-up.
Where to keep the write-up
Keep it near the thing that failed. A review filed in a folder called 'Incidents 2025' is hard to find when the same monitor fires again. A review kept beside the monitor, or beside the follow-up task, gets read.
In AperioFlow, the follow-up task can sit in the same place as the monitor and the error that caused it, so the person who gets the alert also sees the action that came out of the last one. Alert emails go only to people in your organisation, so the review stays with the team that needs it. You can download your data at any time if you want a copy outside the service.
A copyable template
Put this in whatever you use, and fill it in within two days of the fix:
Incident: [short name]
Date: [full date, e.g. 14 March 2025]
Duration: [start time] to [end time]
Affected: [pages, customers or jobs]
Timeline
- [time, full date]: [event]
How we found out: [monitor / customer / by chance]
Why that route: [one sentence]
What restored service: [one or two sentences]
What stops it recurring: [one or two sentences]
One change
- Change: [specific action]
- Owner: [name]
- Due: [full date]Read it back a month later. If the change was made and the same fault has not returned, the review did its job.
If you want the follow-up to sit next to the monitor that caught the fault, you can start free at https://app.aperioflow.co.uk/#/signup. The free plan includes 10 monitors.