Imagine the same incident from two angles.

Angle one: a customer at 2pm tries to log in, gets an error, refreshes, gets the same error, opens your status page. They want to know — quickly, in their own language — whether this is your problem or theirs, how long it'll last, and whether they need to find a workaround.

Angle two: an engineer at 5pm, now that the fix is deployed and the dust has settled, sits down to write a postmortem. They want to capture what actually happened, technically. Where the bug was. Why monitoring didn't catch it earlier. What the team is changing so it doesn't repeat.

These are the same incident with completely different audiences and different write-ups. The status page belongs to angle one. The postmortem belongs to angle two. Mixing them up — putting engineering detail on the status page, or customer-facing fluff in the postmortem — produces both worse customer communication and worse engineering analysis.

Here's the dividing line.

What goes on the status page

Three things, in customer language:

1. What's broken. Specifically the customer-facing surface, not the internal cause. "Login is failing" is right. "Auth-svc-2 is failing health checks" is wrong.

2. Who's affected and for how long. Time bounds where you have them: "since 14:42, all customers." Without the time bound, customers can't tell whether this incident is recent or has been ongoing for hours.

3. What's next. Either the fix is identified and an ETA is realistic, or you're investigating with a next-update time. Customers who close the tab knowing "they're working on it, next update by 15:30" are calmer than customers who close the tab knowing only "investigating."

What's NOT on the status page:

Internal service names ("connection pool exhaustion," "core-api-3," "the cache layer").
Speculation about the cause before you know.
"Five Whys" or contributing-factors analysis.
Engineering action items.
Anything customers wouldn't understand without a glossary.

The status page is the customer-facing surface. Every word on it should make sense to someone who doesn't know what a database is. Reserve the rest for the postmortem.

What goes in the postmortem

The postmortem is where the technical story lives. (See Postmortems for Small Teams for the four-section template that fits on one screen.)

The postmortem can — and should — include:

Technical root cause, with the specifics. What broke, how it broke, what triggered it.
Timeline with engineering detail. When the deploy went out. When the alert (or absent alert) fired. When the fix was identified.
Why monitoring didn't catch it earlier (if applicable).
Action items: specific, owned, dated.

The postmortem audience is smaller and more technical. Engineers reading the postmortem are trying to learn — what does this team need to add to its runbook, monitoring, or process?

What's NOT in the postmortem:

Customer-friendly euphemisms. The customer-facing version of an out-of-memory restart is "the service briefly restarted." The postmortem version is "out-of-memory kill on the auth pod" because that's what actually happened.
Marketing reassurance. "We take our customers' trust seriously" belongs in apology emails, not in a technical analysis.

The two predictable failure modes

Teams confuse the two surfaces in two specific, predictable ways.

Status page is too technical. A team posts "We're investigating a connection pool exhaustion in our auth service." The team thinks they're being transparent. The customer thinks: what's a connection pool? What's an auth service? What does this mean for whether I can log in? They have to translate the language internally before they can react. Many of them just close the tab and email support, defeating the point of the status page.

The fix is to translate aggressively. "Connection pool exhaustion" → "our login system briefly couldn't accept new requests." "Auth-svc-2" → "logins." Every internal noun has a customer-facing equivalent; use the customer-facing one.

Status page is too sparse. The opposite failure: "Issue investigation underway. Updates to follow." Then 45 minutes later: "Issue resolved. Thanks for your patience." Two updates, total. Customers can't tell what happened, what was fixed, or how long it lasted from the post-incident state alone. The incident is technically closed but trust took a hit because customers learned nothing.

The fix is to write the resolution update like it's a one-paragraph story. "Between 14:42 and 15:18 (36 minutes), customers couldn't sign in. The issue was a temporary failure of our login system; we've restored service and added monitoring to catch similar issues earlier. A full write-up will be available within 48 hours."

That's still customer language — no internal nouns, no technical jargon — but it tells the customer what happened, who was affected, for how long, and what's next. The "full write-up" reference is where the postmortem comes in.

The over/under-share trap

The over/under-share trap shows up specifically at the resolution update. Teams have two failure modes at that step:

Over-share. Treating the status page resolution as if it were the postmortem. The update includes a timeline, a root cause, contributing factors, the whole technical analysis. Customers don't need any of it. Most won't read it. The few who do will skim for the "what got fixed" line and move on.

Under-share. "Resolved." That's it. No story, no impact summary, no timeframe. Customers who lived through the outage learn nothing about what just happened. Trust evaporates because the resolution feels like the team is rushing to close the ticket.

The middle is where the resolution update should live. One paragraph. Customer impact. Timeframe. What was fixed. Pointer to the postmortem for those who want the technical depth. That's enough.

The handoff

The clean handoff between the two surfaces sounds like this on the status page resolution:

"Resolved at 15:18 — login was unavailable for 36 minutes due to a temporary issue with our login system. We've restored service and are investigating root cause. A full write-up will be published within 48 hours."

And then the postmortem, published 24–48 hours later, picks up the story with full technical detail. Engineers who care can read the deep version. Customers who got their resolution update can move on with their day.

The status page and the postmortem aren't competitors. They're different documents for different audiences. The status page is operational; the postmortem is reflective. Both should exist, and both should respect what the other is for.

When you only get one

For minor incidents — a 5-minute blip with one customer report — the postmortem might be a Slack note, not a formal write-up. (See Postmortems for Small Teams for when each version applies.) In those cases, the status page entry is the only customer-facing artifact. That's fine — the format still applies. Customer-facing language. Time-bound. What happened, what's fixed.

The smaller the incident, the simpler both surfaces. The bigger the incident, the more they each need to do their specific job.

The framing

Customers and engineers want different things from an incident write-up. Customers want to know what just happened to them, briefly, in language they can parse. Engineers want to understand what just happened to the system, in depth, so they can prevent it.

Two surfaces. Two audiences. Two write-ups.

The teams that respect this come out of incidents with their customer trust intact and their engineering reflection intact. The teams that don't end up with customer-facing pages full of jargon and postmortems full of marketing language — bad service to both audiences, in different ways.

Pick your audience. Write for them. Pointer to the other surface when the reader wants more.

PageCalm helps small teams run status pages with AI-powered incident updates that sound human and ship fast. Try it free — no credit card required.

How Much Detail to Publish on Your Status Page (and What Belongs in the Postmortem)