Every Update Names the Next

Before the detail — Decision: send updates on a stated cadence, and make every update name the next one. Outcome: an audience that stops guessing whether anyone is still working the problem, and a comms log the record can point to. Artifact: four filled templates, one per audience, each stamped with a next-update time. Status of what follows: a default with a stated escape hatch, not a fixed rule; one clause is a binding federal requirement, named where it applies.

Prompt first: draft the update, not the excuse

Here is who this update goes to: {{internal | customers/field crews
| executives | regulator/agency}}, and here is that audience's
approved template [paste].

Here is what we know right now [paste: impact, in one sentence;
who is working it; what changed since the last update, if anything].

Fill only that template from the facts above. Rules:
  - state what we do not know yet, explicitly - do not omit it
  - name a specific next-update time, even if the honest content
    is "no change"
  - do not explain the cause to a customer or a crew - that goes in
    the postmortem, not the status page
  - for the regulator template, leave the trigger family and rule
    citation blank if I did not paste them - do not infer one

If nothing has changed since the last update, draft the update that
says so on time, rather than skipping it.

The templates exist so drafting an update is retrieval, not composition — the assistant fills fields from what is pasted, and a human decides what belongs in each one.

A cadence with an escape hatch

The fetched guidance says: “Provide updates every 30 minutes (or whatever cadence is appropriate for the situation).” That second clause is not a loophole — it is the rule. Thirty minutes is a default with an escape hatch, not a standard, because a five-minute-old outage and a five-hour slog need different rhythms.

Four stages carry an update through its life: Investigating, Identified, Monitoring, Resolved. Each is a claim about what the team currently believes, and moving backward — from Identified to Investigating, say — is a legitimate update, not a failure to report cleanly.

The first template fired after declaration is internal, and it sets the tone for everything that follows: state what is known, state what is not known yet (“say this explicitly — it stops the guessing”), name the commander and the comms lead by name, and give a next-update time “even if nothing has changed.” A California utility’s own outage rule makes the same point from a different angle: when identifying a major outage, the utility must say explicitly when no restoration estimate is known, rather than going silent — an honest unknown is not an admission, but silence reads as one.

The next-update field turns a broadcast into a promise

A status-page template’s skeleton runs title, plain-language statement, who is responding, impact — and one field that changes everything: “We will send an additional update in [N] minutes.” Publishing a fact is optional in most of life; publishing a promise with a number attached is not, because the next update is now a commitment the audience is holding you to, not a courtesy.

The customer and field-crew template makes the same discipline concrete for a different audience: no cause, no ETA, no apology paragraph — a crew needs to know what to do in the next ten minutes, not why it broke. “What a crew cannot do, in their words, not ours” and “the fallback, concretely” are the two fields that matter; causes belong in the postmortem.

Severity gates who receives an update, not how it is written. The fetched incident-communications guidance warns: “In the heat of a P1, every minute spent crafting a polite status update for executives is a minute not spent fixing the root cause.” So the answer is not a different tone, it is a shorter, five-bullet document, sent only past a stated severity threshold: impact, timestamps, whether the incident is customer-visible, whether data is involved (“this is the question they will ask”), which reporting clocks have started, and what is needed from the reader — “usually nothing — say so.” Data Products 6.1 (a separate training in this series) answers the same question one level down: an alert goes to a person who can act on it, not to a channel.

Publishing is not notifying

A regulator template looks like the others but carries one different sentence at the top: “DRAFT — legal and the clock owner review before this leaves.” It asks for the entity, the incident reference, the detected time, the trigger family that actually started the applicable clock, the instant that family occurred, and the rule that governs — with an explicit rule: if the citation does not resolve to a real source, the notification is not ready to send. “Known at this time” and “not yet determined” sit side by side, because an honest unknown, timestamped, is a valid thing to send a regulator.

FedRAMP’s RFC-0031 (the federal cloud-authorization program’s incident-communications rules) contains the one measurable public-availability rule found anywhere in this research. Class C and D offerings MUST maintain a public status page with at least 30 days of history in human- and machine-readable forms; Class A and B SHOULD. This is a live obligation on the certification path’s own schedule, not a proposal: FedRAMP adopted RFC-0031 into the Consolidated Rules for 2026, effective 2026-07-04 and mandatory from that date for a provider seeking a 20x certification, from 2027-01-01 for Rev5 or a pilot 20x, and said the final rules were adjusted from the RFC on feedback — so read the MUST/SHOULD split against the published rules, not the RFC text, before you rely on it.

None of that discharges the duty this training has spent two lessons on. A subscriber reading a status page and a named agency contact reading a required notice are two different acts, and the clock behind the second one does not pause while the first one gets written. 4.2’s clocks run on their own instants regardless of what the public page says.

Stop and escalate when a promised next-update time is about to pass with nothing new to say — send the update anyway, on time, stating plainly that nothing has changed. A missed promise costs more trust than an honest “still investigating,” and the comms lead takes that call to the commander for the words, never to skip the send.

Key takeaway

Thirty minutes is a default cadence with a stated escape hatch, not a fixed rule, and the field that matters most in any template is the promise of a specific next update — sent on time even when nothing has changed. Severity decides who receives an update, not how it reads: the same facts, gated by audience, from a one-sentence internal note to a five-bullet executive brief to a legal-reviewed regulator draft. Publishing a status page never discharges a duty to notify a named recipient, and the clock behind that duty runs on its own instant regardless of what the public page says. The next lesson turns to what a notification must contain once it is time to send one.

LEADERSHIP DECISION   require every status update to name its own
                      next update, with no exception for "nothing
                      to report"
PRACTITIONER ACTION   fill the four templates from paste-only
                      facts, gate distribution by severity, and
                      treat an unresolved next-update time as an
                      open item the commander owns
SUCCESS MEASURE       zero missed promised-update times across a
                      quarter's incidents - calendar time held
                      against the audience's expectation, not just
                      the regulator's