Start with the observed interruption
This original fictional example concerns an internal booking page. All times use America/New_York. At 09:10, two test booking attempts failed. That observation identifies affected paths to investigate; it does not establish the root cause, severity, or impact on every user.
The Atlassian incident-response description connects coordination, investigation, recovery, and review. The procedure below is an original service-coordination example, not production commands or a universal security-response process.
Incident ID: DEMO-I01. Observed impact: two supplied test attempts failed. Cause: UNKNOWN. Closure rule supplied by this fictional team: both designated booking paths must pass recovery checks and the incident lead must review the evidence. That is an example-specific condition, not an SLA or standard for every service.
Assign roles and preserve the timeline
| Time | Record type | Entry | What remains open |
|---|---|---|---|
| 09:10 | Observed | Two designated booking-path attempts failed. | Scope and cause need investigation. |
| 09:15 | Assigned | Sam coordinates; Jo investigates; Rae handles communications. | Actual investigation and update evidence to record. |
| 09:25 | Proposed | A configuration correction is proposed. | Approval and application not supplied. |
| 09:35 | Observed | One designated path has a successful test. | Second required path NOT TESTED; lead review pending. |
| 09:45 | Planned | Next update is planned. | No sent update evidence supplied. |
Keep who recorded each observation and where its evidence lives in the actual operating record. A short timeline is useful when a second responder can distinguish these states without reconstructing the conversation.
Define the response gates
Report and coordinate: Record the affected task, time zone, observed test failures, and incident owner. Use the organization's actual escalation rules; leave severity unassigned if the relevant facts or rule are missing.
Investigate: Jo gathers the evidence needed to examine the failure and records hypotheses as hypotheses. A proposed configuration correction does not establish a cause. Retain the observed symptom separately from the suspected explanation.
Authorize the change: Follow the actual service's approval and change procedure. The 09:25 entry remains proposed until the record supplies approval and application evidence. This template does not instruct someone to execute a production fix.
Validate recovery: Check each required path and record its actual result. At 09:35, one of two designated paths passed and the other is untested. The correct example state is Recovery check pending, not Resolved. Do not assume the proposed correction caused the success when its application is unconfirmed.
Review closure: Present both path results and remaining exceptions to the incident lead. Record the actual decision; a checkbox or a green status label cannot supply that approval.
Keep the update truthful
An internal review note at 09:35 could read: “One booking path passed a test. The second designated path has not been tested, and closure review is pending. Cause remains unknown. Next update planned for 09:45 America/New_York.” This is original fictional review copy, not a notification that was sent.
Rae should use the approved communication channel and record the actual update when it occurs. Keep planned time and sent evidence distinct. After the active interruption is handled, retain unresolved investigation questions for the team's later review rather than inventing a final root-cause explanation.
Copy a coordination-procedure prompt
Create one complete, self-contained US-English HTML companion for “DEMO-I01 · service incident review”. Return the full HTML document, with inline CSS and any JavaScript needed for the local interactions. Use the original scenario, named records, numbers and expected cases below.
Design the page for this task: use clearly labeled input or source records, a readable result or worked example, and an adjacent explanation of the evidence. Use a restrained visual hierarchy, left-aligned text, readable tables or stacked records, and a responsive layout at 720px and 360px. Provide meaningful labeled controls for Timeline; Coordination roles; Recovery & closure; Select text. Use keyboard-accessible native controls and visible focus. Keep the complete content readable without an external dependency.
The following brief supplies the substantive content and constraints. Native-format requests describe the material to represent or copy manually; this HTML must not pretend to create DOCX, XLSX, PDF, PPTX, H5P or another native file, run Python/Flask/Django/Snowflake/Power BI, connect a live service, send messages, or perform an authorized real-world action. Where the task requires a native source, actual observation or separate approval, retain that requirement and leave unsupplied evidence blank.
Draft an original service-incident coordination SOP in US English. Incident/task scope, ID and observed impact: [inputs]
Timeline with time zone and evidence references: [inputs]
Coordinator, investigator, communications and closure authority: [inputs]
Actual escalation/change rules and approval evidence: [inputs]
Required recovery paths and supplied closure conditions: [inputs]
Planned/actually sent updates and operating record format: [inputs]
Separate reporting/coordination, investigation, authorized changes, recovery validation and actual closure review. Label observed,assigned,proposed,applied,planned and unknown facts accurately. A suspected cause is not confirmed; a proposed change is not applied. Require each specified path's evidence before claiming the closure condition is met. Keep next-update plans separate from sent notifications. Do not invent severity, SLA, root cause, approvals, production commands, test results or security-breach remediation. Retain untested paths and use [NEEDED: input] for gaps. Optional HTML review controls reveal evidence only; no remediation, dispatch, notifications or approval automation. Return the authorized original record format.
COMPLETE AUTHORED SCENARIO AND EXPECTED CASES
The following is the supplied reading/teaching/calculation record to represent in the companion. Preserve its particular content, examples, source references and unknowns. Wording about a future native implementation refers to that native task, not permission to omit this HTML companion.
# Incident Management SOP Template: Keep the Service Interruption Open Until the Checks Are Complete
One successful test can show progress without proving that a disrupted service has recovered. Give the incident record a fixed timeline, named coordination roles, and explicit recovery checks. Separate observed impact from a suspected cause and a proposed fix from a change that was actually applied.
## Start with the observed interruption
This original fictional example concerns an internal booking page. All times use America/New_York. At 09:10, two test booking attempts failed. That observation identifies affected paths to investigate; it does not establish the root cause, severity, or impact on every user.
The [Atlassian incident-response description](https://www.atlassian.com/incident-management/incident-response) connects coordination, investigation, recovery, and review. The procedure below is an original service-coordination example, not production commands or a universal security-response process.
**Incident ID:** DEMO-I01. **Observed impact:** two supplied test attempts failed. **Cause:** UNKNOWN. **Closure rule supplied by this fictional team:** both designated booking paths must pass recovery checks and the incident lead must review the evidence. That is an example-specific condition, not an SLA or standard for every service.
## Assign roles and preserve the timeline
| Time | Record type | Entry | What remains open |
| --- | --- | --- | --- |
| 09:10 | Observed | Two designated booking-path attempts failed. | Scope and cause need investigation. |
| 09:15 | Assigned | Sam coordinates; Jo investigates; Rae handles communications. | Actual investigation and update evidence to record. |
| 09:25 | Proposed | A configuration correction is proposed. | Approval and application not supplied. |
| 09:35 | Observed | One designated path has a successful test. | Second required path NOT TESTED; lead review pending. |
| 09:45 | Planned | Next update is planned. | No sent update evidence supplied. |
Keep who recorded each observation and where its evidence lives in the actual operating record. A short timeline is useful when a second responder can distinguish these states without reconstructing the conversation.
## Define the response gates
**Report and coordinate:** Record the affected task, time zone, observed test failures, and incident owner. Use the organization's actual escalation rules; leave severity unassigned if the relevant facts or rule are missing.
**Investigate:** Jo gathers the evidence needed to examine the failure and records hypotheses as hypotheses. A proposed configuration correction does not establish a cause. Retain the observed symptom separately from the suspected explanation.
**Authorize the change:** Follow the actual service's approval and change procedure. The 09:25 entry remains proposed until the record supplies approval and application evidence. This template does not instruct someone to execute a production fix.
**Validate recovery:** Check each required path and record its actual result. At 09:35, one of two designated paths passed and the other is untested. The correct example state is **Recovery check pending**, not Resolved. Do not assume the proposed correction caused the success when its application is unconfirmed.
**Review closure:** Present both path results and remaining exceptions to the incident lead. Record the actual decision; a checkbox or a green status label cannot supply that approval.
## Keep the update truthful
An internal review note at 09:35 could read: “One booking path passed a test. The second designated path has not been tested, and closure review is pending. Cause remains unknown. Next update planned for 09:45 America/New_York.” This is original fictional review copy, not a notification that was sent.
Rae should use the approved communication channel and record the actual update when it occurs. Keep planned time and sent evidence distinct. After the active interruption is handled, retain unresolved investigation questions for the team's later review rather than inventing a final root-cause explanation.
Implement the local companion rather than returning a text-only plan. Preserve every numerical fixture and the distinction between illustrative expectations and actual evidence. Any native-runtime or classroom tests mentioned above remain tests to perform in the proper environment; do not mark them passed. Keep edits and practice responses in this open page only, without claiming persistent storage. Provide invalid/missing-input feedback and reset behavior that agree with this specific brief. Do not claim accessibility certification, learning gains, real approvals or test results that were not observed.
Review the missing evidence with the team
Keep actual response actions and approvals in the authorized operating system. Finish the review by assigning the second path check and closure decision to their actual owners while preserving what remains unknown.