Write incident updates that keep customers informed

Tell readers what changes for them

When a service is unsettled, customers need enough information to decide whether to wait, retry or use another path. Start with the affected action and what your team is doing. Do not lead with an internal component name that only your engineers recognize.

Separate observations from explanations. “Some bookings are failing” can be accurate before you know why. If you have not established a cause or a restoration time, say so. A promised next update is easier to keep than an unsupported promise that everything will be fixed by then.

Make the first update useful

The example below is fictional. Replace the service, impact and time with facts you have checked. Include a timezone, and choose a next-update time someone is responsible for meeting. Do not claim unaffected features are healthy unless you have verified them.

Taking a closer look
We spotted an issue affecting new bookings. Some customers may be unable to finish a booking. Our team is investigating. We will share another update by 14:30 UTC, even if the investigation is still underway.

Keep the next message honest

An update can be useful even before you have a fix. Say what remains affected, whether a safe workaround exists, and when you will return with more information. Avoid repeating the same reassuring phrase without any new context.

For example: “New bookings are still affected. We are checking a change to the booking service. Please avoid repeated submissions if you are unsure whether a booking completed. Our next update will be by 15:00 UTC.” Only give that retry advice when it matches the actual behavior of your application.

Review before your words go public

UptimeOwl public status pages are available on Business and Enterprise. An owner or admin with the relevant permissions can save a private incident draft, review it and publish explicitly. A detection can seed a private draft; it does not publish raw diagnostics automatically.

Use customer-facing component labels and remove private URLs, account identifiers, logs and credentials. Saving changes does not replace the published wording until you publish again. Pick a person to review updates so parallel investigations do not become contradictory public messages.

Describe recovery, then close the loop

When a fix is applied, distinguish watching recovery from declaring the incident resolved. Verify the affected customer action and watch for a steady result before publishing a resolution. A successful monitor check does not automatically resolve a public incident in UptimeOwl.

A fictional resolution might read: “Bookings are completing again. We have verified the recovery and are closing this incident. Thank you for bearing with us.” Add any remaining customer action only when one is needed, and keep a retrospective separate from the immediate recovery note.

Published updates form the incident timeline. This feature does not send subscriber emails. For planned work, use a maintenance notice with a clear window, and configure monitor maintenance separately if alerts should be quiet during that work.

Further reading

• Incident communication practices — Atlassian