Practical guide

Write an incident note that helps the next person

Last materially reviewed 2026-09-26

Quick answerSeparate the observed failure, its suspected cause and the action actually taken.
What to know

Start with the observation

Write the affected address, monitor type, first recorded failure and the time zone. Then state what the check actually reported: an HTTP error, a timeout or a missing keyword. Do not translate a failed request into a claim that every customer was unable to buy. Different paths, regions and logged-in states can behave differently. Preserve that boundary in the first sentence rather than correcting an exaggerated conclusion later.

What to know

Keep hypotheses labelled

A recent release or hosting notice may be relevant, but timing alone does not establish the cause. Maintain separate lines for observed facts, a working explanation and information still missing. Record who owns the investigation and the next update time. A small business does not need an elaborate incident system to avoid losing this distinction; one accessible, consistently structured note can be sufficient.

What to know

Document the change

When someone makes a repair, record what they changed and when, without placing credentials or private customer information in a shared note. Identify the person who can explain or reverse that change. If an outside supplier acted, link its official incident notice where useful and distinguish its stated resolution from your own verification. Avoid recording a permanent root cause until supporting evidence exists.

What to know

Close with a bounded result

Finish with the checks that passed after the intervention and the tasks still untested. A fictional example is: public homepage returned expected content at 14:20; payment confirmation remains unchecked. That is more useful than a blanket all fixed message. Choose a follow-up owner for missing evidence and retain the note long enough to inform the next review, following your own information-handling policy. Include the next unresolved check and its named owner.

Continue when useful

Next: What to check after an uptime alert clears

A green monitor closes one observation, not necessarily the customer incident.

Open What to check after an uptime alert clears →

Sources used for this page

These records support the facts and comparisons above. Merchant-controlled records are labelled so you can separate product claims from independent evidence.

  1. UptimeRobot: website monitoring — Merchant documentation · uptimerobot.com · Merchant-controlled · checked 2026-09-26
  2. UptimeRobot: status pages — Merchant documentation · uptimerobot.com · Merchant-controlled · checked 2026-09-26