Update Cadence Commitment

Two hours into an outage, somebody senior asks when it will be fixed. The honest internal answer is usually a branch: three hours in the good case, a day in the bad one, and nobody yet knows which. The number that gets spoken becomes a commitment, and the condition attached to it does not travel with it. Support repeats it to customers, an account manager repeats it to a client, the status page inherits it.

The update cadence commitment replaces a prediction you do not control with a promise you do. "I will tell you which case we are in at 15:00" is keepable. "Three hours" is a guess wearing a commitment's clothes.

Why it matters

When the stated time passes without resolution, the incident acquires a second problem. The conversation shifts from the outage to your credibility, the requests for updates increase in frequency, and the person best placed to fix the system is pulled into producing them. The organisational failure frequently outlasts the technical one.

There is a trust mechanism underneath. Publishing "no change, next update at 15:30" on schedule is what proves the silence is not concealment. Stakeholders escalate mainly when they suspect information is being withheld, and a reliable rhythm removes the suspicion at a cost of one message every half hour.

Implementation patterns

• Fixed interval, same channel, same format, decided before an incident rather than during one. Thirty minutes suits most major incidents; fifteen during customer-visible payment failures.
• Every update ends with the next update's time. This single habit is what stops people asking in between.
• Publish "no change" updates. The empty update is the one that builds the trust; skipping it is what restarts the questions.
• Separate restore from recover from reconcile. Service restored, data consistent, and backlog cleared are three different times, and a stakeholder hears one word. Report all three explicitly or be misunderstood.
• State scenarios with their decision points, not point estimates: "if X by 15:00 then roughly three hours, otherwise a day; I will tell you at 15:00."
• Give the decision-maker the trigger, not the timeline. They are usually asking in order to decide something — notify customers, invoke a clause, move to manual processing. Answer that question, advising the reversible option while uncertain.

Industry example

Public status-page practice at large providers converged on this shape: timestamped updates at a stated interval, with explicit "we will provide another update in 30 minutes" lines, even when there is nothing new. Atlassian's April 2022 incident review is a useful counter-case, describing the difficulty of communicating with affected customers over a restoration that ran from 5 to 18 April, when the product that would normally carry the message was itself unavailable.

Failure scenarios

• The travelling number, repeated externally without its condition, which turns an engineering estimate into a customer commitment.
• Silence during the hardest hour, read as concealment, producing an escalation that consumes the responders.
• Cadence drift, where updates slip from 30 to 50 to 90 minutes as fatigue sets in, exactly when confidence is thinnest.
• The responder as the communicator, so progress stops for the duration of each update. Assign a separate communications role early.
• "Fixed" declared at restore, followed by a second wave of complaints from the unreconciled data.

Trade-offs

The cadence costs someone's full attention for the length of the incident, and it deliberately withholds a number that stakeholders want. In exchange it protects the responders' attention and the team's credibility, both of which are needed more in hour six than in hour one. Teams that skip the separate communications role save one person and pay for it in repair speed.

When not to use it

For a short, small incident, the ceremony exceeds the event. A ten-minute degradation affecting one internal tool needs a message when it starts and one when it ends. The rhythm is for incidents that are customer-visible, long enough for people to start asking, or severe enough that somebody senior is watching. Applying it to everything produces update fatigue, and the channel's signal value falls exactly when a real incident needs it.

Interview question

Q: You are running a major incident. Twenty minutes in, the CEO joins the channel and asks for an ETA and a customer impact number. Neither is known. What do you say, and what do you do next?

What a strong answer covers: committing to an update time and a scenario framing rather than an ETA · giving a bounded impact statement with its uncertainty ("between 5% and 20% of checkout requests; I will have the real number at 14:45") · naming the decision they may need to make and which way to lean while uncertain · assigning a communications role so responders are not pulled away · and setting the cadence explicitly in the channel so nobody has to ask.

Quick check

Quiz: Why publish an update that says nothing has changed? Because a reliable rhythm is what demonstrates that silence is not concealment, which is what stops escalation.

Flashcard: What is the only time commitment you can safely make during an incident? — When the next update will arrive.