After the outage: what a small SaaS publishes, and when
Customers forgive an outage more easily than silence. The order of things a small SaaS publishes during and after one: the first status update within half an hour, updates on a timer, the customer email, the one-page write-up a week later and credits applied without a claim; with wording to copy and what Atlassian, Cloudflare and GitLab did in public.
Every software product goes down. For a small SaaS it is usually something dull: a certificate that expired, a database that ran out of disk, a deploy that went out on a Friday, a cloud provider having a bad afternoon. Customers mostly forgive the outage. What they remember is what you said, how fast you said it, and whether the explanation a week later made them trust you more or less.
This piece is the order of things to publish during and after an outage, with wording you can copy, what larger companies did well and badly in public, and what to set up now, on a quiet day, so you are not writing your first status update in a panic.
What customers are reading for
During an outage a customer wants three facts: is it you or them, what is affected, and when they will hear more. Afterwards they want two: what happened, and why it will not happen the same way again. Enterprise buyers read for one thing more: whether you are the kind of vendor who tells them, or the kind they have to chase. Security questionnaires and contracts now ask for exactly this (notice of incidents within a set time, a root cause report within a set number of days), as we covered in the first enterprise contract.
The cost of silence is well documented. In April 2022, a maintenance script at Atlassian deleted the sites of 775 customers; some were without their tools for up to 14 days. Atlassian's own post-incident review is frank about the communication: the deleted sites took the administrators' contact details with them, the support form required a valid site address that no longer existed, and "we should have implemented broader communications much earlier." Affected customers got individual replies first; the broad public statement came days into the outage.
The timeline
The four status words are the ones Atlassian's Statuspage uses, and most status tools copy them: Investigating (you see the symptoms but not the cause), Identified (you know the cause and are working on a fix), Monitoring (the fix is out and you are watching), Resolved (back to normal). Using them means customers know where you are without reading every word.
The first message
The first update is the one that matters most and the one founders delay, because they want to know the cause first. Don't wait. A short honest message at minute twenty beats a detailed one at hour three:
What makes it work: a time with a time zone, what users actually see (not "degraded performance on a subset of services"), a word on data, which is the first thing people worry about, and a time for the next update, which you then keep. Avoid three things: guessing an end time you do not know, blaming a supplier by name while it is still going on, and "some users may be experiencing issues" when you know many are.
Where the status page lives
On something that does not share your servers. A status page on the same machine, database or provider as the product goes down with it, at exactly the moment it is needed. Hosted status services start free or cheap; a static page on a different host and domain also works. Let customers subscribe to updates by email, and keep your customer contact list exportable outside the product, so that an outage that takes the product down cannot take your ability to email customers with it. That was Atlassian's hardest lesson.
The write-up a week later
The public write-up (post-mortem, incident report, root cause analysis: the name does not matter) is the part that turns an outage into trust. Two public examples show the range.
Cloudflare, 18 November 2025. Much of the web stopped loading for several hours when a database permissions change doubled the size of a configuration file for Cloudflare's bot management feature, and the software that read it failed. The write-up was published the same day, under the chief executive's name, with a timeline in UTC from the first failure at 11:20 to full recovery at 17:06, the cause in technical detail, an apology ("We are sorry for the impact to our customers and to the Internet in general") and four specific changes. Same-day publication is unusual; the shape is the one to copy.
GitLab, January 2017. An engineer working late removed data from the main production database while trying to fix a replica; about six hours of data (issues, comments, new accounts) was lost, and several of the backup methods turned out not to work. GitLab kept a public document of the recovery and streamed it live on YouTube, and published its post-mortem ten days later. It is still read today because it admitted everything, including the backups that had never been tested.
For a small company, the write-up can be one page:
Write it about the system, not a person. If one tired engineer could delete production data, the problem is that one tired engineer could do it. The "how did we not notice for forty minutes" line is often more useful than the cause itself.
Credits
Large providers make customers claim service credits. Amazon's compute SLA, for example, gives 10% of the monthly bill below 99.99% uptime, 30% below 99% and 100% below 95%, and only if the customer files a support case with dates, resource IDs and logs by the end of the second billing cycle. A small vendor can do better at very little cost: work out the credit yourself and apply it to the next invoice before anyone asks, and say so in the write-up. A few days' worth of subscription for a few hours of downtime costs less than one cancelled account, and it is the line customers quote back to you.
Set it up on a quiet day
- A status page on separate hosting, with email subscriptions on.
- An export of every customer's admin contact, refreshed weekly, stored outside the product.
- The first-message template above, saved where whoever is on call can find it.
- One person who writes updates while another fixes; in a team of two, the fixer posts a one-line update on a timer.
- Monitoring that tells you before customers do. If customers are usually your alarm, fix that first.
- A note of which suppliers your product depends on and where their status pages are.
Most of this is half an hour of work, and the first time you need it you will not have half an hour.
Write the update while you fix the problem: pick the phase, say what is affected and when the next update is due, and get status page text, a customer email and a write-up outline to copy. Free, in your browser.
Open the outage update writerSources
Atlassian, Post-incident review on the April 2022 outage (775 customers, up to 14 days, lost contact details, support form, "broader communications much earlier"); Atlassian Support, Create an incident (Statuspage) (investigating, identified, monitoring, resolved); Cloudflare, Cloudflare outage on November 18, 2025 (timeline, cause, apology, follow-up steps); GitLab, Postmortem of database outage of January 31 (published 10 February 2017; data lost, live stream, public document); Amazon Web Services, Amazon Compute Service Level Agreement (credit table and claim deadline). Pages read on 17 October 2026. The timeline, message and write-up templates are our own suggestions for a small vendor.