Incident Management on StatusDrop: From First Alert to Resolved
What this guide covers
StatusDrop monitors your third-party dependencies automatically, but some things only you can announce: a bug in your own code, a database migration, a planned maintenance window. This guide walks through the incident tooling end to end:
- Opening an incident and choosing affected services
- Posting timeline updates through the lifecycle
- Scheduling maintenance windows
- Getting subscribers notified automatically
- What your visitors see
Opening an incident
Go to your stack in the dashboard and open the Incidents tab, then New incident.
- Title -- short and factual: "Elevated error rates on checkout", not "Something broke".
- Impact -- none, minor, major, or critical. This drives the banner color on your status page.
- Status -- new incidents usually start at Investigating.
- Affected services -- pick the services involved. They are highlighted on the public page.
- First update -- the body of your first timeline message. Say what users are experiencing and that you are on it.
The moment you create the incident, a banner appears at the top of your public status page and your confirmed email subscribers get a notification.
The lifecycle: Investigating to Resolved
Incidents move through four statuses, and each update you post can advance the status:
| Status | When to use it |
|---|---|
| Investigating | You know something is wrong but not why. |
| Identified | You found the cause and are working on a fix. |
| Monitoring | A fix is deployed; you are watching for recurrence. |
| Resolved | Confirmed fixed. The banner moves to incident history. |
Post an update whenever the situation materially changes -- and even when it does not. During a long incident, "still investigating, next update in 30 minutes" beats silence every time.
Each update is timestamped and renders newest-first on the public page. Resolved incidents stay visible in the incident history section for 30 days.
Scheduled maintenance
Maintenance is a first-class type, not a repurposed incident. From the Incidents tab, choose Schedule maintenance and set a start and end time.
Your status page handles the rest automatically:
- Before the window: an "upcoming maintenance" banner shows the scheduled time.
- During the window: the banner switches to active, with a timeline entry posted for you.
- After the window: the maintenance completes itself and moves to history.
The transitions run on a one-minute scheduler. You can also advance or close a window manually at any time.
Subscriber notifications
If your status page has the subscribe box enabled (Status Page tab, "Show subscribe box"), visitors can opt in with their email. Subscriptions are double opt-in: they confirm via a link before receiving anything.
From then on, every incident update and maintenance announcement is emailed to confirmed subscribers automatically -- there is no separate "send notification" step to forget during an outage. Every email includes a one-click unsubscribe link.
You can review and remove subscribers from the Notifications tab.
What visitors see
On your public status page, an active incident renders as a banner above the service list: title, impact color, current status, and the full timeline. Maintenance renders the same way with its scheduled window. Resolved items collapse into an expandable history below the services.
Everything also flows into your status page's RSS feed, so users who prefer a feed reader over email still get the story.
Good habits
- Open incidents early. An incident with "Investigating" and one sentence beats ten support tickets asking if you know.
- Close the loop. Post a final update explaining the cause when you resolve. Users forgive outages; they do not forgive silence.
- Schedule maintenance ahead of time. The upcoming banner does the announcing for you.
- Let dependency monitoring do its job. You do not need to open incidents for a Stripe outage -- StatusDrop already shows it on your page. Reserve manual incidents for your own systems.