Back to blog
·PageCalm

What to Write on Your Status Page During an Outage

incident communicationstatus pagestemplates

Your service just went down. You know what's broken — or at least you're figuring it out. Now you have to write something on your status page.

And you're staring at a blank text box.

This post is for that exact moment. Practical templates you can grab, adapt, and post. No theory, no frameworks — just words that work.

The first update: acknowledge fast

The most important update is the first one. It doesn't need to be detailed. It needs to exist.

Within 5 minutes of knowing something is wrong, post this:

We're currently experiencing issues with [affected service]. Our team is investigating and we'll post updates as we learn more.

That's it. You're not committing to a cause, a timeline, or a fix. You're telling people: we know, we're on it.

Real examples:

We're seeing elevated error rates on our API. Investigating now and will update shortly.

Some users may be experiencing trouble logging in. We've identified the issue and are working on a fix.

Our dashboard is loading slower than normal. We're looking into it.

The worst thing you can do is wait until you have a full picture. By then, your customers have already assumed the worst.

Identifying the cause

Once you know what's happening, say so. Be specific about what's affected without getting into internal architecture.

Template:

We've identified the cause of [symptom]. [Brief, non-technical explanation]. We're [current action] and expect to have an update within [timeframe].

Real examples:

We've identified a database performance issue causing slow page loads across the dashboard. We're working on scaling up capacity and expect to have an update within 30 minutes.

The login issues are caused by a problem with our authentication provider. We're in contact with them and monitoring the situation. We'll update in 15 minutes.

We've traced the API errors to a recent deployment. We're rolling back now and expect service to recover within the next few minutes.

What to include and what to skip

Include:

  • What's broken (in user-facing terms)
  • That you've found the cause
  • What you're doing about it
  • When you'll update next

Skip:

  • Internal blame ("a developer pushed bad code")
  • Deeply technical details ("the pg_stat_activity shows 500 blocked connections")
  • Exact resolution times you're not confident about

Progress updates: even "no change" is an update

If it's been 20-30 minutes and you're still working on it, post something. Silence after an initial update is almost as bad as no update at all.

Template:

Update: We're still working on [issue]. [What you've tried or are doing]. Next update in [timeframe].

Real examples:

Update: The database issue is ongoing. We've added additional capacity and are seeing some improvement, but response times are still elevated. Next update in 20 minutes.

Update: Still in contact with our auth provider. They've identified the issue on their end and are deploying a fix. We'll update once we see recovery.

Update: The rollback is taking longer than expected. We're monitoring closely. Next update in 15 minutes.

The key: always include when you'll update next. It gives people a reason to stop refreshing and wait.

The resolution update

When things are fixed, say so clearly. Don't be vague about it.

Template:

Resolved: [Issue] has been resolved. [Brief explanation of what happened and what you did]. All services are operating normally. We apologize for the disruption.

Real examples:

Resolved: The API errors have been resolved. A recent deployment caused unexpected load on our database, which has been rolled back. All endpoints are responding normally. We apologize for the 45 minutes of disruption.

Resolved: Login issues are fixed. Our authentication provider experienced an outage that affected sign-in for approximately one hour. No user data was affected. Sorry for the inconvenience.

Resolved: Dashboard performance is back to normal. We identified a query optimization issue and deployed a fix. Page load times are back under 500ms.

What makes a good resolution update

  • Clearly say it's resolved — don't make people guess
  • Brief explanation of what happened (one sentence)
  • Confirm things are back to normal
  • Apologize without groveling

Severity matters: match your tone

Not every incident is a full outage. Your tone should match the severity.

Minor (degraded performance, cosmetic issues):

Some users may notice slower load times on the dashboard. We're aware and working on it. Core functionality is unaffected.

Major (key features broken, widespread impact):

We're experiencing a significant outage affecting our API. Most requests are returning errors. Our team is actively working to restore service and we'll update every 15 minutes.

Critical (total outage, data concerns):

All services are currently unavailable. We've identified the cause and our engineering team is focused on restoring service as quickly as possible. We'll post updates every 10 minutes. We understand the impact this has and we're treating this as our top priority.

The common mistake is treating every incident like a critical outage. If your API is 200ms slower than usual, you don't need the "all hands on deck" tone. Match the energy to the impact.

Things to never write

  • "We're experiencing intermittent issues." This tells the reader nothing. What issues? Affecting what?
  • "This should be resolved shortly." Should? Either you know or you don't. If you don't, say "we're working on it" instead.
  • "We apologize for any inconvenience this may have caused." The word "may" makes it sound like you don't think it was a big deal. Drop the "may."
  • "Our team is aware." Good — now tell them what your team is doing about it.
  • "Per our SLA..." Nobody wants to hear about your SLA during an outage. That's a conversation for after.

The hard part isn't knowing what to write

If you've read this far, you probably noticed something: these templates aren't complicated. The words aren't hard.

The hard part is writing them while you're also trying to fix a production issue. Translating "connection pool exhausted, queue depth 847" into "we're experiencing elevated response times" takes a mental context switch that's genuinely difficult under pressure.

That's exactly why we built PageCalm. Paste your monitoring alert or describe what's happening, and AI generates a professional status update in seconds. You review it, edit if needed, and publish. Your subscribers get notified automatically.

The templates above will always work. But if you want them written for you in the moment that matters most, give PageCalm a try — the free tier includes 10 AI-generated updates per month.


Bookmark this page. You probably won't need it today. But when you do, you'll be glad it's here.

Stop wordsmithing during outages

PageCalm writes your incident updates so you can focus on fixing what's broken.

Get Started Free