Keep Customers in the Loop When Something Goes Wrong

Overview

When something breaks, your customers notice. What they remember afterward is not just the outage itself but how you communicated during it. Silence erodes trust; a steady stream of honest updates builds it, even while things are on fire.

This guide walks through a complete outage as a timeline: what to set up before anything breaks, what happens automatically when it does, and what you communicate at each stage until the incident is resolved and written up. It ties together incident management and status pages into a single communication workflow.

Step 0: Before the Outage — Set Up the Page

Good incident communication is mostly preparation. By the time something breaks, the channel to your customers should already exist.

1. Create a status page. Pick a unique slug — your page is hosted at {slug}.upti.my — or serve it from a custom domain like status.yourcompany.com. See Status Pages for setup details.
2. Link components to healthchecks. Add a component for each user-facing service and link it to the healthchecks that monitor it. Linked components update their status automatically (Healthy, Degraded, Down, Maintenance, or Unknown) based on check results, so the page reflects reality without anyone touching it.
3. Enable subscriptions. Visitors can subscribe by email with double opt-in confirmation. Confirmed subscribers are notified when incidents are created, updated, and resolved, and about maintenance — so customers hear from you instead of discovering problems on their own.

Step 1: Detection — The Incident Opens Automatically

When a healthcheck fails or a heartbeat is missed, upti.my creates an incident automatically with a severity of critical, high, medium, or low. Deduplication guarantees one open incident per affected resource: repeat failures attach to the existing incident instead of creating duplicates, so your team — and later your customers — follow a single thread per problem.

Recovery is automatic too. When the check comes back healthy, the incident auto-resolves, and if the service briefly fails again within about 5 minutes, the same incident reopens rather than a new one being created. A flapping service produces one coherent story, not a confusing burst of separate incidents.

At this point the incident is still private. Nothing is on your status page yet — but if the affected healthchecks are linked to components, those component indicators have already changed, giving visitors an honest at-a-glance signal while your team decides what to say. For the full lifecycle mechanics, see Incident Management.

Step 2: The First Customer Update

Aim to post your first public update within about 5 minutes of detection. You do not need a root cause — "We're investigating elevated errors on the API" beats silence every time. Customers who see an acknowledged incident stop refreshing, stop guessing, and stop filing duplicate support tickets.

Publishing takes one deliberate action:

• From the dashboard: mark the incident as public and choose which status pages it should appear on.
• From the CLI: publish an existing incident, or create a manual one already attached to a page.

# Publish an existing (automatically created) incident
uptimyctl incidents publish <incident-uuid>

# Or create a manual incident directly on a status page
uptimyctl incidents create \
  --title "Elevated error rates on the API" \
  --severity high \
  --status-page <status-page-uuid>

# Changed your mind? Take it back off the page
uptimyctl incidents unpublish <incident-uuid>

Once published, the incident appears on the selected status pages with its public updates, and subscribers are notified by email. Meanwhile, have a responder acknowledge the incident in the dashboard — acknowledgement feeds your MTTA metric and tells the rest of the team someone owns it.

Step 3: Ongoing Updates

Incidents move through a structured lifecycle — Created, Acknowledged, Investigating, Identified, Monitoring, Resolved — and each transition is a natural moment to tell customers where things stand. Between transitions, post a follow-up every 15 to 30 minutes, even if it is just "still working on it." A quiet incident page reads as an abandoned one.

# Public update (updates are public by default on a published incident)
uptimyctl incidents add-update <incident-uuid> \
  --message "Root cause identified: a failed deploy. Rolling back now."

# Internal-only updates are also available for notes
# your team should see but customers should not.

This is where selective updates earn their keep: keep raw debugging notes internal, and publish the distilled version. Every public update appears on the status page timeline and is emailed to subscribers; the page itself refreshes automatically, so visitors see new updates within about a minute without reloading.

Step 4: Resolution

When the check recovers, the incident auto-resolves — but do not let the auto-resolution be your last word. Post a clear resolution message: what happened, what was affected, and confirmation that service is restored. The resolving update notifies subscribers, so this message is what closes the loop for everyone who was following along.

On the status page, linked components return to Healthy on their own as check results come back clean, and the uptime bars record the blip.

Step 5: After — Post-Mortem and History

Once the dust settles, attach a post-mortem to the incident. It can be written inline or loaded from a file:

# Inline post-mortem, published as a public update by default
uptimyctl incidents post-mortem <incident-uuid> \
  --message "A config change caused connection exhaustion. We've added..."

# From a file, kept internal
uptimyctl incidents post-mortem <incident-uuid> \
  -f postmortem.md --no-public-update

Publishing the post-mortem as a public update tells customers you understood the failure and did something about it. The resolved incident remains on the status page's history page along with its public timeline — and that is a feature, not a liability. An honest incident history builds more trust than a suspiciously spotless one.

Planned Work: Maintenance Windows

Not every disruption is an outage. For planned work, schedule a maintenance window in advance: alerts are suppressed for the duration, the status page shows the affected components in a maintenance state, and subscribers are notified when the window is scheduled and again when it completes. Announced maintenance reads as competence; unannounced maintenance reads as an outage.

Automating Subscriber Notifications

If you orchestrate incident response with workflows, you can add a Status Page destination node to notify verified email subscribers with a templated message as part of your response flow. Note that the node only fires for incidents linked to that status page — publish the incident to the page first, then let the workflow handle the notification.