The alert fires. Login is broken. Your engineer is three terminal windows deep into a debugging session, scrolling through stack traces. Customers are starting to email support. Someone needs to post on the status page. Who?

The default instinct is "whoever's fixing it." It's the worst answer.

The engineer fixing the bug is the person you most want focused on the bug. Pulling them away to write customer-facing copy — to translate technical detail into plain language, draft a tone-appropriate update, pick the right severity label, hit publish — costs you minutes of debugging at the worst possible time. And the writing suffers, because they're context-switching from "what's breaking" to "what would a non-technical customer think reading this." The output is rushed, often too technical, and harder for customers to act on.

There's a better split. It works at every team size, including teams of one — and decided in advance, it's almost free.

The two jobs

Posting a status update is actually two jobs:

Gathering the facts. What's broken, who's affected, when did it start, what's the team doing about it. This has to come from whoever's closest to the system — usually the engineer, or the on-call.

Writing and posting the update. Translating those facts into customer-facing language, picking the right severity, hitting publish. This doesn't have to be the same person. Anyone with the right voice and access who isn't actively debugging can do it.

Most teams collapse the two jobs because they look like one job from outside. They're not. The first is "extract the truth from the system." The second is "communicate that truth to the audience." Different skills. Different time pressures. Different people, ideally.

How this maps by team size

The split looks different depending on how many people you have. The principle stays the same.

Solo founder (team of 1)

You're both. The trick is to separate the jobs in your own head, not in different humans.

A practical pattern:

Investigate for 3–5 minutes without touching the status page. You won't learn anything useful enough to post in the first 60 seconds anyway, and the panic of "but I haven't posted yet" makes the investigation worse.
Then explicitly stop investigating for 60–90 seconds and post the first update. Treat that 90-second block as protected time — you're not investigating during it.
Then back to investigating. Set a timer for the next update window (15–30 minutes). When the timer fires, stop investigating again, post.

The key is the "explicitly stop" part. Trying to context-switch every 30 seconds between debugging and writing produces both bad debugging and bad writing. A 90-second block of focused communication, then a 20-minute block of focused investigation, is dramatically better than a continuous blend.

Team of 3 (engineer + support + founder, or similar)

Now the split is across humans, which is much easier.

Engineer: investigates. Drops one-line factual updates into a shared Slack channel as they learn things. Doesn't write customer-facing copy.
Founder or support: monitors that channel, translates the engineer's updates into customer-facing copy, posts to the status page.

The engineer doesn't have to write polished prose. A one-liner like "auth service crashed, ~50% login failures, restart deploying now" is perfect — it's facts, not customer copy. The poster translates that into "We're seeing issues with login affecting some customers (about half of sign-in attempts are failing). We're deploying a fix now and expect recovery within a few minutes."

This pattern delivers faster updates and better-written ones. The engineer doesn't context-switch. The poster doesn't have to guess at facts. Both jobs get done in parallel.

Team of 10 with on-call rotation

At this size, you can afford a dedicated comms role per incident — sometimes called an "incident commander" or "comms lead," but the title matters less than the responsibility. One person owns customer-facing communication for the duration of the incident. That person isn't debugging. They're reading the technical channel, translating, posting, monitoring customer reports, replying to social media when needed.

The on-call engineer never touches the status page during the incident at this scale. Their job is one job.

The Slack-relay pattern

For a 2–3 person team, the most reliable pattern is what's effectively a Slack-relay:

Set up a dedicated incident channel — #incidents, or per-incident channels (#incident-2026-05-06-login). Doesn't matter which, just be consistent.
Engineer drops short factual updates into the channel as they learn things. No formatting required, no audience-awareness required.
Poster watches the channel and translates significant updates into customer-facing posts.
The status page is updated by the poster, not the engineer.

A few patterns that make this work better:

The poster doesn't ask "should I post this?" for every line the engineer drops. They use judgment. New significant fact = post-worthy. Routine debugging chatter = not.
The poster echoes back the customer-facing copy in the channel before publishing it. Quick sanity check from the engineer ("yes, that's accurate") catches errors. Doesn't need a long review — 5 seconds.
The engineer doesn't "approve" each post in a way that creates a bottleneck. Default is "post unless you stop me."

Done well, this pattern produces near-real-time customer updates without ever taking the engineer's attention off the fix.

The "I don't know who's doing it" trap

The single most common failure mode in small teams is no one posting because no one decided who was responsible. The engineer assumes someone else is on it. Support assumes the engineer is on it. The founder is in a meeting. Twenty minutes pass. Nothing on the status page. Customers start asking on social media. Then someone posts, and the team looks slow.

The fix is to decide in advance, not during the incident. Even for a team of two, the rule should be one sentence in a runbook:

"When an incident is happening, [Person A] gathers facts; [Person B] writes and posts to the status page. If [Person B] is unavailable, [Person A] does both."

That's it. The decision takes 60 seconds to make and saves you 20 minutes during every future incident.

For a team of one, the rule is a different one-liner:

"When an incident is happening, investigate for 5 minutes, then explicitly stop and post. Set a timer for the next update."

These rules aren't enforcement mechanisms. They're just pre-decisions. The point is to not have to decide while the alarm is ringing.

The voice question

Whoever writes, the voice should be consistent across incidents. Customers reading your status page over time learn what your team sounds like; whiplash between three different voices makes the page feel less coherent.

Practical implication: if a team of three has the engineer post sometimes and support post other times, the posts will read differently — engineers tend toward technical detail, support tends toward customer-empathy phrasing. Neither is wrong, but the inconsistency is read as the team being scattered.

Better: pick one voice for status page posts, and have whoever writes them match that voice. If support is the usual poster, engineer-written posts (when support isn't available) should still sound like support wrote them. This is easier than it sounds — read your last five status page posts before writing a new one and the voice tends to come through.

What to avoid

A few patterns that look reasonable but produce worse incidents:

The engineer being the bottleneck for posts. Every update has to be approved by the engineer before publishing. Sounds rigorous; produces 30-minute gaps between updates while the engineer is heads-down.
The poster guessing at facts they don't have. "I think it's the database" written without confirmation from the engineer. When the actual cause turns out to be something else, the team has to walk back the speculation publicly.
Multiple people posting without coordination. Two updates fired in 30 seconds, slightly contradicting each other. Customers see the team flailing.
Silent investigation. The engineer posts an initial "investigating" update, then nothing for two hours while debugging. Even with no new facts, a "still investigating, no new findings" update at the 30-minute mark prevents customers from concluding the team forgot.

(See How Often Should You Post Updates During an Incident for the cadence side of this.)

Pre-incident decisions worth writing down

Before the next incident, even if your team is two people, decide:

Who has status page access? Both people, or just one? (If just one, who's the backup when they're unavailable?)
Where do incident facts get relayed? Specific Slack channel, specific text thread, in-person?
What's the rule when the primary poster is unavailable? Default fallback to the engineer, or wait?
Who writes the resolution update? This often matters more than the during-incident updates — the resolution is the most-read post, and it's the one most often phoned in. Owning it explicitly helps.

These decisions take 15 minutes to make. They cost zero to write down. And they make every future incident faster.

The principle

Writing status page updates during an incident is a job, with its own skills and its own time pressure. Treating it as something the busiest engineer does in their spare time is what produces the worst status pages.

Even small teams can split this. The cost is one decision, made in advance, about who does what when. The benefit is faster updates, better writing, and an engineer who actually gets to focus on the fix while customers are kept informed.

Decide before the incident. Stick to the decision during it.

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.

Who Should Post Status Updates During an Incident?