Markdown incident update template: facts during a disruption

An incident update speaks to people affected by a disruption that is still happening. They need to know whether the service they depend on is affected, what the team can confirm and when another notice will arrive. A short Markdown file can hold those facts without waiting for a full explanation of the problem.

The reusable text below keeps current observations separate from open questions. Its fictional example concerns room availability at Doe Holdings. It does not attempt to explain the eventual cause or set a recovery deadline.

Write for the interruption happening now

Name the service in the headline, then describe what people cannot do. Calling it a "service issue" leaves the affected activity unnamed. "Doe Room Finder cannot show room availability" names both the service and the missing function.

Give the notice an observation time, including a time zone. That time establishes how fresh the statements are. It is distinct from the next notice time, which tells people when they can expect to hear again.

If this is your first .md file, an introduction to Markdown files explains the extension. Here, the file's purpose is a timely account of confirmed impact, rather than a diagnosis for the people trying to repair the service.

The incident update template

Use this block as the starting text for your incident file. Substitute observations confirmed at the stated time for its prompts. An unanswered question can stay unanswered in the notice; it needs clear wording rather than a speculative answer.

# [Affected service]: [confirmed interruption]

Update as of [TIME AND ZONE]. Prepared by [DOE PLACEHOLDER NAME].

## Confirmed impact

[Who is affected and which function is interrupted, based on current observations.]

## Current work

[What the team is doing about the interruption now.]

## Still unknown

[What has not been established about the cause or extent of the interruption. State when the time of return is unknown.]

## Next notice

The next notice will be at [NEXT NOTICE TIME AND ZONE], even if no new finding is confirmed by then.

The headline carries the immediate problem. Confirmed impact expands it only as far as the evidence allows. Current work describes an activity under way, while Still unknown marks the limits of that account. The last paragraph gives a time for another notice, not a time by which the repair will succeed.

Doe Holdings and its room service

Doe Holdings, Jane Doe and Doe Room Finder are fictional placeholders. The interruption and all observations in this example are invented. Bracketed times stand in for actual observation and notice times; neither is a recovery estimate.

# Doe Room Finder: room availability cannot be viewed

Update as of [CURRENT TIME AND ZONE]. Prepared by Jane Doe for Doe Holdings.

## Confirmed impact

People using Doe Room Finder cannot view room availability. Attempts to open the room availability screen show no room details.

## Current work

The team is examining the failed attempts to open room availability and comparing them with the last confirmed working attempt.

## Still unknown

The cause has not been established. The team has not yet confirmed whether other functions are affected. We do not know when room availability will return.

## Next notice

Jane Doe will provide another notice at [NEXT NOTICE TIME AND ZONE], including if the investigation has no new confirmed finding.

The impact paragraph describes an observable limit: no room details appear. It does not turn that observation into a claim that every function has stopped. The unknowns paragraph preserves that boundary by saying that other functions have not yet been assessed.

Current work names the comparison the team is making. It does not claim that the comparison has found an explanation. Jane Doe's name identifies the person preparing the notice, without assigning fault for the interruption.

Separate evidence from expectation

Describe impact in terms the affected person can recognize. "Cannot view room availability" concerns the activity they came to perform. Technical guesses about the underlying failure add uncertainty to that plain account. Keep a suspected explanation out until it has been established.

Be equally precise about scope. If observations cover only one function, say so. Silence about another function does not establish that it is working. An explicit gap prevents a narrow observation from becoming a claim about the whole service.

The repair's finish time may also remain unknown. A next notice at [NEXT NOTICE TIME AND ZONE] is a commitment to communicate then. It gives no basis for expecting the interruption to end at that moment. Keep those two ideas apart in the wording.

Blank lines divide the sample's labeled time paragraph from the impact heading and its explanation. Paragraph separation in Markdown describes that syntax. A short paragraph per subject also leaves each uncertainty beside the statement it qualifies.

Follow-up notices and the final note

At the announced time, revise the same incident file around the latest confirmed observations. Replace the observation time and retain impact that still applies. Describe any change in current work, retain unresolved questions and name the next notice time. When nothing new is confirmed, say that plainly rather than filling the gap with a guess.

For the fictional service, a follow-up paragraph could read: "As of [FOLLOW-UP TIME AND ZONE], room availability remains inaccessible. The comparison is continuing, and no cause has been confirmed. The next notice will be at [LATER NOTICE TIME AND ZONE]." The continuing interruption remains the central fact even though the investigation has no new result.

When service returns, use a brief final note such as: "At [CONFIRMATION TIME AND ZONE], the team confirmed that Doe Room Finder again displays room availability. This is the final notice for this interruption." Include only functions whose return has been confirmed. Leave any later investigation of causes and future changes to a separate account after the repair.

Keep the service name in the filename

For this invented case, doe-room-finder-interruption.md identifies the service and the reason for the file. Retaining that name through follow-up notices keeps the continuing event recognizable. Guidance on naming Markdown files covers word separators and other naming choices.

Before using a fresh copy for a different interruption, replace the service name throughout the text. A leftover headline or old next notice time could mislead someone even when the new impact paragraph is accurate. Read the notice as someone trying to decide whether the stated interruption affects their work.

Where Sashmark fits

AI agents leave people with Markdown to read and revise; Sashmark is intended as a desktop app for that work. Reading and editing remain planned work for this app, still in development. Its planned role here is reading and editing an incident update file; the team remains responsible for every statement about the disruption. Sashmark contains no AI.