iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
A status-page update should tell customers what is happening now: which service is affected, what users may experience, what responders are doing, and when they will hear from you again. A bug report or postmortem has a different job: recording what happened, when it happened, why it happened, and what will change afterward. That distinction matters more than enforcing present tense in every sentence.
Why a status page and a bug report use different time frames
A customer-facing status page is a live view of an incident. Readers need a useful picture of the current situation, and the team should revise the update as it learns more. Atlassian describes adding incident updates to reflect the current status as a cause is identified and later fixed: What is an incident?
A bug report or postmortem preserves the event for later understanding. It can establish a chronology, explain the cause and mitigation, and identify follow-up work. Past tense often makes that account clearer because the incident and response have already occurred. The practical rule is to keep the live update centered on the present, then use the retrospective to explain the past—not to ban past-tense sentences from status pages.
What to include in a live status-page update
Write a compact update around five reader questions:
#1 Best Overall
- What is the current state? Say whether the team is investigating, has identified the cause, is monitoring a fix, or has resolved the incident.
- What is affected? Name the service, component, or user group where known.
- What is the impact? Describe observed symptoms in terms customers can recognize, not only internal system details.
- What is the team doing? State the action underway, without presenting an unconfirmed explanation as fact.
- When is the next update? Give a time or an interval for the next communication, even if the investigation has not produced an estimated fix time.
If the cause is still unknown, say that investigation is ongoing. If a mitigation is in place but the team is checking whether symptoms have stopped, say the service is being monitored. Avoid promising a fix time that responders cannot support.
How incident states should change as responders learn more
Atlassian Statuspage documents four incident states. Use the label together with a plain-language explanation; the label alone may not tell a customer what to expect. See Atlassian’s incident-status definitions.
Rank #2
- Used Book in Good Condition
| State | When it fits | What to tell readers |
|---|---|---|
| Investigating | Symptoms are visible, but the cause is not yet known. | Describe the observed impact and say the team is investigating; do not state a suspected cause as confirmed. |
| Identified | The cause is known and a fix is underway. | Explain the confirmed cause at an appropriate level and what action is in progress. |
| Monitoring | A fix appears successful, and the team is watching for remaining or returning symptoms. | Say that a fix or mitigation is in place and that responders are monitoring the service. |
| Resolved | The cause has been eliminated and systems have returned to full performance. | Mark the incident resolved only once service has recovered, rather than when a fix is merely deployed. |
How often to update users during an outage
Atlassian recommends updates every 30 minutes, or another cadence appropriate to the situation, so users are not left without information while an incident remains open. This is operational guidance, not a measured guarantee that a particular interval will reduce confusion or support requests. See Atlassian’s incident communication tips.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Choose a cadence the team can meet, and make the next update time explicit. If there is no material change, a brief update can still confirm that investigation or monitoring continues. Keep the factual status aligned across the status page, email, and social channels; translate technical detail into user impact and acknowledge the disruption.
What belongs in a bug report or postmortem
Once the incident is resolved, the retrospective can provide the durable account that a live update cannot. PagerDuty’s postmortem template supports recording a detailed timeline, causes, mitigation, and follow-up actions. Organize the account so a reader can understand:
- What began and when users were affected.
- What symptoms customers experienced.
- What responders did and how the mitigation or recovery unfolded.
- When public status-page communication occurred.
- When service recovered and how the team determined the incident was resolved.
- What corrective or preventive work will reduce recurrence.
Separate confirmed causes from contributing factors and questions that remain unresolved. Record the time each status-page update was published in the retrospective timeline; PagerDuty’s template also calls for links or logs that support the timestamps. That makes the incident record more useful than a sequence of approximate recollections.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.A practical example: the same incident, two kinds of writing
Live update: “Some customers cannot complete checkout. We are investigating the cause and will post another update in 30 minutes.” This reports the current impact and action without claiming an unconfirmed cause or fix estimate.
Recommended Free Tools
Later retrospective: “At 09:10 UTC, checkout failures began. The team investigated, applied a mitigation, and monitored transactions before resolving the incident at 10:05 UTC. The follow-up actions are…” Use actual incident facts and timestamps in a real report; the example illustrates chronology, not a claim about a particular outage.
Best Value
When the present-tense rule should bend
A status update may refer to a past event when that context helps customers understand the current state—for example, noting that a mitigation was deployed before explaining that monitoring continues. What matters is that the main message answers what is true now. Conversely, a postmortem can describe ongoing follow-up work in the present or future; its purpose is still to preserve the incident history and explain what comes next.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
