Status pages and incident communication: the complete guide

Every product goes down eventually. Customers rarely leave over a single outage. They leave when they find out from Twitter, wait an hour for a reply and never learn what went wrong. Incident communication is the part you control.

This guide covers the whole job: what to put on a status page, how to write each update, how to handle maintenance and other people's outages, what uptime numbers really allow and how to choose a tool. It includes a free incident update writer and an uptime calculator. Where Quackback does something relevant, we say so; the status page for SaaS page goes further.

What a status page is for (and what it isn't)

A status page is where you tell customers whether your product is working. It lists the parts of your service, shows the current state of each, and keeps a timestamped record of incidents and scheduled maintenance. When something breaks, it's the one place everyone can check without asking you.

It does three jobs:

• Answers "is it down?" before it's asked. Every customer who finds the answer on your status page is one fewer message in your inbox while your team is busy fixing things.
• Builds trust over time. A history of honest, prompt updates is evidence that you take reliability seriously. Silence during an outage does the opposite.
• Keeps the record. Uptime history and past incidents are what customers, prospects and auditors look at when they ask how reliable you are.

A status page isn't monitoring. Monitoring checks your systems and tells your team something is wrong. A status page tells your customers. Some tools bundle both; many teams keep them separate and let the monitoring tool update the status page through an API when a check fails. Either way, a person should write the words customers read.

Quackback is a status page without monitoring. You set each component's status by hand, or your monitoring tool does it through the Status API.

Components and severity

Components are the parts of your service a customer would recognise: the web app, the API, sign-in, email delivery, webhooks, each region. Name them the way customers do, not the way your infrastructure does. "Checkout" means something to a customer; "payments-worker-eu" doesn't.

• Keep the list short. Five to fifteen components is enough for most products. Too many and nobody can tell what matters.
• Group them when you have regions or product areas, so customers can find theirs.
• Add a one-line description where the name alone could be read two ways.

Severity describes how bad it is for customers. A common scale, and the one Quackback uses, gives each component one of five states:

Agree what each level means before you need it, ideally with examples for your own product, so nobody argues about labels during an incident. When in doubt, pick the more severe state. Customers forgive you for overstating a problem far more readily than for understating one.

In Quackback, an incident's overall impact (minor, major or critical) follows the worst component it affects, and you can override it when the components don't tell the whole story.

The four stages of an incident update

Most incidents follow the same arc, and most status pages name the stages the same way: Investigating, Identified, Monitoring and Resolved. Using the standard names helps, because customers already know what each one means.

Investigating. Post as soon as you know customers are affected, before you know why. Say what's affected and what customers will notice.

We're investigating reports that the dashboard is failing to load for some customers. We'll post an update within 30 minutes.

Identified. You know the cause and what you're doing about it. Explain it in plain words.

We've found the cause: a database upgrade that didn't complete. We're rolling it back now. Next update within 30 minutes.

Monitoring. A fix is in place and you're watching to make sure it holds.

We've applied a fix and the dashboard is loading normally again. We're monitoring to make sure it stays that way. Next update within 1 hour.

Resolved. It's over. Say when it started and ended, what customers experienced and what happens next.

This incident is resolved. From 14:05 to 14:50 UTC, some customers couldn't load the dashboard. The cause was a failed database upgrade, which we've rolled back. We're sorry for the disruption. A full write-up will follow within five business days.

You won't always need every stage. A quick fix can go straight from Investigating to Resolved. What matters is that customers never have to wonder whether you're still working on it.

Our incident communication templates have fill-in-the-blanks versions of each stage, plus scheduled maintenance. In Quackback, save them as incident templates and insert one with a click when you post.

Writing updates people trust

An incident update is read by worried people in a hurry. Write for them.

• Lead with the impact. "Some customers can't sign in" beats "We are experiencing elevated error rates on our authentication service."
• Say who's affected. A region, a plan, a feature or everyone. If you don't know yet, say so.
• Always give a next-update time, and keep it. "We'll update within 30 minutes" turns an anxious wait into a known one. If you have nothing new, post that you're still working on it.
• Don't guess the cause. Saying "a DDoS attack" and later correcting it costs more trust than "we're still investigating".
• Skip the jargon and the hedging. No "a subset of users may be experiencing intermittent issues". Say "some customers see errors when they save".
• Tell customers what to do, if anything: retry, wait, use a workaround, or nothing at all.
• Apologise once, at the end. One sincere sentence in the resolved update is better than a sorry in every post.
• Use UTC or name the time zone every time you give a time.

The writer below turns a few answers into a status page update, an email and a reply for your inbox, all saying the same thing. It uses fixed templates, not AI, so the output is predictable.

Dashboard is partly unavailable

Investigating: We're investigating reports that Dashboard is unavailable for some customers. You may see errors when loading reports. We'll post an update within 30 minutes.

Subject: [Investigating] Dashboard is partly unavailable

Hi,

We're investigating reports that Dashboard is unavailable for some customers. You may see errors when loading reports. We'll post an update within 30 minutes.

Follow every update on our status page: status.example.com

You're receiving this because you subscribed to updates for Dashboard.

Hi [first name],

Thanks for letting us know. Dashboard is unavailable for some customers right now, and our team is investigating. You can follow live updates at status.example.com. We'll post the next one within 30 minutes.

[Your name]

Scheduled maintenance

Planned work deserves the same care as an incident, and it's easier, because you choose the timing. A good maintenance notice says:

• what you're doing, in a phrase
• the start and end time, with the time zone
• what customers will notice: nothing, slowness, read-only mode or downtime, and for how long
• anything they need to do before or after

Announce it early. A few days' notice is typical for routine work, a week or more for anything customers might need to plan around. Pick a window when the fewest customers are active, which may not be the middle of the night where you are.

Post when it starts and when it ends. If it runs over, say so before the window closes, with a new estimate.

In Quackback, scheduled maintenance can start and finish on its own at the times you set, moving its components to Under maintenance and back. Subscribers get an email when you schedule it. Time spent under maintenance doesn't count against a component's uptime.

Third-party outages

Sometimes the problem isn't yours. Your cloud provider, CDN, payment processor or email service goes down, and your product breaks with it. On 18 November 2025, for example, Cloudflare's network began failing at 11:20 UTC. Core traffic was largely back by 14:30 and every system was normal by 17:06. Products that sit behind Cloudflare broke for their own customers at the same time, through no fault of their own.

Your customers don't care whose fault it is. So:

• Post on your own status page anyway, against the components your customers see. "Sign-in is unavailable" is what they need to know.
• Name the provider if it helps, and link to their status page, but don't use it to shift blame. You chose the provider.
• Say what you can and can't do. "We're waiting on our provider's fix" is honest. So is "we're moving traffic to a backup".
• Follow up afterwards with what you're changing: a fallback, a second provider, or a deliberate decision to accept the risk.

Subscribe your team to the status pages of every provider you depend on, and list those dependencies somewhere your on-call person can find them at 3am.

One message, everywhere

During an incident, customers ask in every channel you have: chat, email, social media and your AI agent. If each channel gets its own improvised answer, they drift apart. One says "a few minutes", another says "we're investigating", and customers notice.

Write the update once, on the status page, then reuse it:

• Subscriber email. Tell everyone who subscribed, with a link back to the page for later updates.
• Inbox replies. Save a reply as a macro at the start of the incident, so everyone on the team answers the same way and links to the page. Update it at each stage.
• Your AI agent should answer "is it down?" from the live status page, not from what it learned last week.
• Social posts should be short and point to the page.

In Quackback these sit in one product. Customers subscribe to the whole page or only the components they use. They get an email when you publish an incident or schedule maintenance, and they follow the later updates on the page or its RSS feed. Your team replies from the shared inbox with macros, which are on every plan. On Pro and up, Quackback AI's agent reads your live status page when customers ask whether something is down. Every status event is also a webhook, so you can post updates to Slack or anywhere else.

Postmortems and the changelog

The resolved update closes the incident. A postmortem closes the loop. For anything serious, publish a short public write-up within a few days:

1. Summary: what happened and who was affected, in two sentences.
2. Timeline: when it started, when you noticed, when you fixed it, in UTC.
3. Cause: in plain words, without blaming a person.
4. What you're changing, with dates where you can commit to them.

Cloudflare published its write-up of the November 2025 outage within a day, with a detailed timeline. Few teams need to go that deep, but the principle scales down: explain, own it, say what changes.

Then ship the follow-ups where people will see them. The fixes from a postmortem are product changes, and your changelog is where customers look for those. Link the changelog entry from the incident, and the incident from the entry, so the story is easy to follow.

In Quackback the changelog sits beside the status page, and customers who voted for a related request on your feedback board get an email when you publish the entry.

Uptime and SLAs

Uptime is the share of time a service was available. An SLA (service level agreement) is a contract that promises a level of uptime and says what happens, usually a service credit, if you miss it. Each extra nine cuts the downtime you're allowed by a factor of ten:

Before you sign or publish an SLA, settle the details that decide the number:

• What counts as down. A full outage only, or degraded performance too? One component, or the whole service?
• Whether maintenance counts. Most SLAs exclude announced maintenance, often with a minimum notice period.
• The measurement window. Monthly is usual. A bad day weighs far more in a month than in a year.
• Who measures. Your monitoring, a third party or the customer's own reports.
• The remedy, and how a customer claims it.

Promise less than you deliver. If your last year was 99.95%, a 99.9% SLA leaves room for a bad month.

Quackback shows 90 days of uptime per component. Operational and under-maintenance time count as up; degraded performance and any outage count against it. You can hide uptime for a component where the number would mislead.

Public vs private status pages

Public is the right default. Anyone can check it without signing in, search engines index it, and prospects can see your history before they buy. A public page also does the most to cut "is it down?" messages.

A private page, visible only to signed-in customers, makes sense when:

• the components would reveal customer names or internal systems
• you run dedicated environments for particular customers
• contracts require incidents to be shared only with the affected customer
• the product is internal, for employees or partners

A middle path is audience-specific status: one page, but each group of customers sees only the components it uses. That suits products with regions, dedicated clusters or enterprise tiers.

In Quackback, the status page is on every plan:

A self-hosted install includes every feature. See pricing for the full comparison.

Choosing a status page tool

Start with three questions:

1. Do you want monitoring built in? If you don't already run uptime checks, a tool that includes them saves a setup. If you do, a status page your monitoring can update is enough.
2. How will you be charged as you grow? Status page tools price by subscribers, components, team members or monitors. Work out next year's bill, not this month's.
3. Where does the rest of the conversation happen? An incident creates support conversations and, later, changelog entries. A status page that sits beside your inbox and changelog means one place to work and one message.

Then check the details:

• subscriber email, and whether customers can choose components
• scheduled maintenance that starts and ends on its own
• update templates
• an API and webhooks, so monitoring and chat tools can join in
• uptime history, and whether you can hide it per component
• a custom domain and your own branding
• private or audience-specific pages, if you need them
• who hosts it, and where

Host the page somewhere that won't go down with your product. If your status page runs on the same servers as your app, it fails exactly when you need it.

Quackback's status page suits teams that want incident communication next to their help center, inbox, feedback boards and changelog, on every plan, and open source. It doesn't monitor uptime. If you want checks built in, a dedicated tool will suit you better.