A subscriber gets an email from your status page at 2:47 PM. They're in the middle of something. They glance at their inbox. Your notification is there, above 14 other unread emails. All they see is the subject line — which is your incident title, prefixed with your company name.

They have one second to decide whether to click. What did you write?

If your title is "Service degradation," they're not opening it. If it's "API issue," same outcome. Those words communicate nothing. They're also what most incidents are titled.

The incident title is the shortest piece of text you'll write during an outage and the one that reaches the most people — email subscribers, status page visitors, anyone seeing a link in a team chat. Most titles are wasted. Fixing them doesn't take more time than writing the bad version; it just takes a small set of rules.

What a title needs to do in 80 characters

Every incident title is competing for attention in an inbox, a feed, a dashboard. It has to answer three questions without requiring the reader to click:

What is affected? Customer-visible surface, not an internal service name.
Who is affected? All users, a region, a subset.
What state is it in? Are you investigating, fixing, recovering, or done?

A title that answers all three is already clearer than 90% of what customers see on status pages.

The pattern that works:

[Surface] [state] [scope if known]

Examples:

"Checkout failing for US-East customers — investigating"

"Dashboard slower than usual — identified, deploying fix"

"Email notifications delayed — recovering"

"Signup unavailable — investigating"

None of these are clever. They're not meant to be. They're meant to be scannable in half a second from an inbox and give the reader enough to decide whether to care and whether to click.

Patterns to stop using

Too generic. "Service degradation." "Platform issue." "API problem." These read as placeholders from an incident template that nobody filled in. If the title could apply to any of your last 20 incidents, it's not a title — it's a label.

Too technical. "core-api-3 high latency." "Redis cluster event." "Kafka consumer lag." These are internal-tool names. The customer doesn't know what Redis is, doesn't know what core-api-3 does, and shouldn't have to. Translate to the customer-visible surface: what were they trying to do that isn't working?

Too alarmist. "MAJOR OUTAGE." "CRITICAL FAILURE." "URGENT — ALL USERS AFFECTED." All-caps titles don't convey severity more effectively; they just look panicked. A calm, specific title carries more weight during a real crisis than shouting does. Customers default to reading severity from the facts and from your badge color, not from your capitalization.

Too hedged. "We're currently investigating reports of what might be slightly slower than usual response times affecting some users." That's 16 words spent on qualifiers. Every hedge weakens the signal. "Dashboard slower than usual — investigating" says the same thing with confidence.

Too vague. "Investigating an issue." An issue where? An issue with what? This is the verbal equivalent of setting off a smoke detector and refusing to say what's burning.

Updating the title as you learn

Titles aren't meant to be set once and forgotten. They should evolve across the incident lifecycle:

Phase 1 — initial detection:

"Dashboard slower than usual — investigating"

Phase 2 — root cause identified:

"Dashboard slower than usual — identified, rolling out fix"

Phase 3 — fix deployed, watching:

"Dashboard slower than usual — monitoring recovery"

Phase 4 — resolved:

"Dashboard slowness resolved"

Each state change is a new title. Subscribers who see the "investigating" email and then see a follow-up "monitoring recovery" email immediately understand the progression without having to read either body. Subscribers who only see the final "resolved" title know what happened and that it's done.

This is worth the small extra work because the title is the part that shows up in email subject lines, push notifications, feed previews — all the places the body doesn't get read. Keeping the title accurate across phases means even people skimming get an honest picture.

One specific habit that makes titles better

Before typing the title, answer this question out loud: "If a customer read only this line, would they know what's happening to them?"

Not "would they understand there's a problem" — what's happening to them specifically. "API issue" doesn't tell them whether their checkout works. "Service degradation" doesn't tell them whether their team's notifications will go through today. "Checkout failing for US-East customers — investigating" does.

This one question filters out most of the bad patterns above. You can't pass it with internal service names (they don't map to customer experience). You can't pass it with generic labels (they don't identify the surface). You can't pass it with all-caps (capitalization doesn't describe symptoms).

Before and after, concretely

A few plausible pairs:

Before: "Intermittent 500s" After: "Some dashboard pages returning errors — investigating"

Before: "Postgres failover event" After: "Database switchover — brief service pause expected, recovering"

Before: "We're currently experiencing some issues with a third-party service which is impacting several features of our platform" After: "Payments processing slow — issue with payment provider, investigating"

Before: "MAJOR: auth system down" After: "Login unavailable — investigating"

Before: "Things are broken 😞" After: "Errors across dashboard and API — investigating"

None of the "after" versions are long. They're not clever. They just name the thing that's broken in customer-facing language and say what state it's in. That's the whole job.

A short checklist

Before publishing an incident, look at your title and run through:

Does it name a customer-visible surface? (Not a service name, not a system component.)
Does it describe a symptom a customer would recognize? (Not "degraded" — "slow," "failing," "unavailable.")
Does it include current state? (Investigating / identified / monitoring / resolved.)
Does it avoid all-caps and unnecessary punctuation?
Could a reader skip the body and still have roughly the right picture?

Five questions. Thirty seconds to run through. Every incident you write, the same five.

Why bothering with this matters

Titles are the piece of incident communication with the highest leverage-to-effort ratio. More people read titles than any other part of your status page — subscribers skimming email, customers glancing at Slack, support looking at the dashboard header, prospects evaluating your reliability history months later. A good title with a mediocre body beats a mediocre title with a brilliant body every single time, because the mediocre body doesn't get opened.

Teams that take titles seriously don't necessarily write better status pages overall. But they write status pages that get read, which is a precondition for any of the other work on that page mattering.

Spend the 30 seconds. Run the checklist. Write the title that does its job.

PageCalm is a status page tool with an AI writer for the moments you don't have time to wordsmith. Try it free — no credit card required.

Writing Incident Titles That Actually Inform