Three repeatable exercises.
Routine afternoon has no active incident. API slowdown affects the Public API and Web dashboard. Sign-in interruption affects Sign-in and dashboard access. These are fictional product components, not URLs or live services.
Scenario selection is shared across the monitor, incident, and status-preview pages through local browser storage. Each incident keeps its own acknowledgment and update history. Switching scenarios does not mix the records.
Choose your scenarioChecks are observations.
State is a summary.
Each component has 24 synthetic checks. The colored strip preserves their order. The final check determines the displayed current health and latest response. A failed response is shown as “No response”, not zero milliseconds.
| State | Interpretation |
|---|---|
| Operational | The example check completed within its normal range. |
| Degraded | The example response was slower than its intended threshold. |
| Outage | The example check did not return a usable response. |
The pass count is a count of sample checks. It is not a measured uptime percentage, a service-level objective, or a guarantee about real availability.
Acknowledgment is not recovery.
Acknowledge locally adds one ownership event and changes the response badge. It leaves service health untouched. Repeated acknowledgment is disabled so the event is not duplicated.
The baseline timeline uses fixed scenario times in UTC. Your local actions include their actual ISO timestamp and are labeled as local exercise events. They are not presented as historical observations from the fictional service.
Say what is known.
Name the next step.
An update should explain observed impact, the current response stage, and the next useful action. Keep a hypothesis separate from confirmed evidence. Avoid claiming a cause simply because two events are close in time.
“Some sign-in attempts are failing in this exercise. We are checking the affected component and will add a recovery update when the next synthetic check is healthy.”
Internal updates stay in the incident room. The Include in public-page preview checkbox is off by default. Selecting it adds that message to the local preview only; it sends nothing outside the browser.
Keep the history.
Change the current state.
Apply local recovery changes the final synthetic check for affected services to Operational and records a recovery event. Earlier degraded or failed checks remain visible. The monitor and public preview therefore show current recovery without erasing the incident.
This action simulates recovery. It does not restart software, change infrastructure, resolve a provider incident, or verify a real endpoint. Reset the exercise to return to the original synthetic state.
Take the chronology with you.
The Markdown export includes the chosen scenario, each service’s current state and check count, baseline incident chronology, acknowledgment/recovery flags, and all local updates with visibility labels. It preserves internal notes rather than silently pretending the report is public-ready.
State is saved only in this browser. Storage can fail or be cleared; visible status text reports save failures. Download a copy if the record matters. No live monitoring, authentication, notifications, subscriptions, payments, or external publication is part of this concept.