You posted an "investigating" update 20 minutes ago. Your engineers are deep in a debugging session. You haven't learned anything new. The status page is quiet. Customers are refreshing it. Do you post again?

Most teams have no real answer to this question. The two defaults are both bad. One team posts aggressively for the first 15 minutes, then goes silent for an hour while they're actually fixing things. Another team posts once, says "we'll update when we have more," and then doesn't, for two hours. Neither of those is intentional — they're just what happens when nobody decided in advance what the cadence should be.

The right cadence isn't a single interval. It changes across the arc of an incident, and it's driven by one principle: your customers need continuous evidence that a team is actively working, not just a log of facts you've confirmed.

Why silence feels different from your side

From the engineer's chair, silence during an open incident feels correct. You're in a Slack huddle, you have three tabs of logs open, someone is rolling a fix, someone else is reproducing the bug, the system is getting your full attention. Posting "still working on it" feels like performative noise.

From the customer's chair, that same silence reads as the opposite: no one is working on this. The last thing they saw was "We're investigating" forty-five minutes ago. Nothing has changed on the status page since. The most reasonable interpretation — absent any evidence otherwise — is that the team posted, went home, and forgot.

This is the asymmetry that trips teams up. Silence on your side feels like focused work. Silence on the reader's side feels like abandonment. The status page is the only channel that resolves that gap, and it only resolves it if you actually use it.

The phases and what cadence each needs

An incident has four phases, and each one has a different natural cadence.

Phase 1: Detection and triage (first 10–15 minutes). You know something is wrong. You don't yet know what. This is the phase where customers are most acutely uncertain — they just hit an error, they're checking the status page right now, and they want to know if it's just them.

Cadence here is fast. First update within 5 minutes of confirming customer impact. Second update within 10–15 minutes of the first if you haven't resolved. These don't have to be substantive — acknowledgment is the whole job. A post like "We're seeing elevated errors on checkout. Investigating now" is sufficient.

Phase 2: Active investigation (15 minutes to an hour or more). You've posted the initial update. You're actively debugging. You may not have root cause yet. This is the phase where teams most often go silent, and it's the phase where reader anxiety grows fastest.

Cadence: every 20–30 minutes, even when nothing has changed. Yes, even when nothing has changed. What changes in these updates isn't the technical detail — it's the proof of continued attention. "Still investigating. We've ruled out X and Y, now looking at Z" is a strong update. So is "Still investigating. No new findings yet, but the team is actively on it." The second one feels thin. It isn't.

Phase 3: Identified, working on the fix (variable, usually 30 minutes to several hours). Now you know what's wrong. You're deploying a fix or scaling up or reverting something. Updates can slow down because there's now a narrative: here's the problem, here's what we're doing, here's what's next.

Cadence: every 30–45 minutes, with substance when you have it. If the fix is rolling out, say so. If you've verified partial recovery, say that. If you're waiting on a deploy to finish, say how long that'll take. The gap between "we know what's wrong" and "it's fixed" is where customers are most willing to wait, but they still want to see the clock moving.

Phase 4: Resolved. One clear, timestamped resolution update. State what was wrong, what was fixed, and that services are back to normal. This update lands differently than all the others — it's where the customer decides how they feel about the whole incident. Don't rush it. Don't write it in a hurry while you're still cleaning up. Take 10 minutes to write it well.

The "nothing new to say" update

This is the update most teams avoid, and it's also the most important one. Teams think of it as contentless. Customers don't.

Consider two versions of the same 45-minute point in an investigation:

The silent version: Nothing on the status page. Last update was at 14:00, now it's 14:45. Customers have been staring at a single "Investigating" banner for 45 minutes. They're emailing support asking if the status page is out of date.

The "nothing new" version: At 14:20, a new update: "Still investigating. We've narrowed the issue to our payment processing layer and are continuing to trace the error." At 14:45, another: "Still working. A fix candidate is being tested internally. We expect to know within 15 minutes whether it resolves the issue."

The second version has almost no incremental technical information. Both updates could be summarized as "we're still working on it." But the difference in how they feel to a reader is enormous. The first reads as a team that has lost interest. The second reads as a team that is methodical, calm, and actively closing in.

The rule: if 25 minutes have passed since your last update and the incident is still open, you post. You can write it in 30 seconds. It's worth 30 seconds.

The "we'll update when we have more" trap

This phrase appears in roughly half of all bad status page histories. It is almost always a setup for silence.

"We're investigating an issue with the API. We'll update when we have more information."

Then 90 minutes of nothing.

The problem with this phrase isn't the words — it's that it transfers the update obligation from a clock to a discovery. The team unconsciously sets the trigger for the next update to be "when something changes." And things don't change on a timer. They change when they change, which could be 45 minutes or four hours.

Better phrasing sets a time-based expectation explicitly: "We're investigating. Next update by 14:30 regardless of whether we've made progress." Then keep that promise. If 14:30 rolls around and you have nothing, post that you have nothing and set the next time.

The act of putting a specific next-update time in writing does two things: it tells the reader when to come back, and it forces your team to actually hit that clock. "We'll update when we have more" is a hope. "We'll update by 14:30" is a commitment.

A simple cadence heuristic

If you want one rule rather than four phases, this works for most incidents:

Post an update at least every 30 minutes while the incident is open, even if nothing has changed. Post a final update when it's resolved. Anything less than that and your status page becomes a false-negative signal.

Faster cadence for early triage. Slower fine once you're in a known fix state. But 30 minutes is the outer limit where a reader stops believing anything is happening.

Teams sometimes push back on this with "we don't want to spam our subscribers." The pushback is backwards. Subscribers to your status page have opted in specifically to hear about incidents. They know what they signed up for. A 30-minute cadence during an active incident is exactly what they're expecting. The spam concern applies to notifications between incidents, not during them.

The deeper reframe

The most useful shift in how to think about cadence is this: the cadence itself is the content.

When you post frequently during an incident, you're not communicating technical information. You're communicating that a team exists, is paying attention, is treating this seriously, and has processes that are working. That message is the one customers actually care about. The technical detail is secondary.

A status page that posts every 25 minutes during an outage — even when half those posts say "still investigating, no new findings" — tells a completely different story than one that posts twice and goes silent for 90 minutes. Same engineers. Same incident. Same resolution time. Completely different customer experience.

You don't need more information to post more often. You just need to decide, ahead of the next incident, that consistent cadence matters more than substance-per-update. Then follow the clock, not the findings.

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.

How Often Should You Post Updates During an Incident?