Status pages
Publish a monitor's health where your customers can read it without asking you.
Two kinds, for two different jobs.
Simple one monitor, created from the monitor's own settings
status.drumbeats.io/<project-id>/<slug>
Advanced many monitors grouped into components, built in the Status Pages section
status.drumbeats.io/<your-slug>Simple one monitor, created from the monitor's own settings
status.drumbeats.io/<project-id>/<slug>
Advanced many monitors grouped into components, built in the Status Pages section
status.drumbeats.io/<your-slug>Use a simple page to share one critical job with stakeholders. Use an advanced page when customers expect a single view of a whole product.
Publish a simple page#
Open the monitor, go to its status page settings, and set:
| Field | What it does |
|---|---|
| Display name | The heading visitors see |
| Description | Short context written for non-operators |
| Slug | The path segment in the default URL |
| Vanity slug | A globally unique name for the short URL form |
show_incidents | Whether incident history is public |
noindex | Asks search engines not to index the page |
is_active | Publish or unpublish without deleting |
Pick a URL form#
| Form | Pattern | Available on |
|---|---|---|
| Default | status.drumbeats.io/<project-id>/<slug> | Every plan |
| Vanity | status.drumbeats.io/s/<vanity-slug> | Any paid plan. Free returns 403 |
Vanity slugs are globally unique across all of Drumbeats and first come, first served. Pick something specific to your product, so acme-billing-cron rather than billing.
Changing a vanity slug breaks every existing bookmark and link. Choose it once.
Decide whether to show incidents#
Showing incident history means visitors see past outages, their durations, and when they were acknowledged. That is the right call for a customer-facing page, where hiding outages costs you more trust than having them.
Hiding it leaves only the current state badge and the description. That suits an internal stakeholder page where "is the invoice job healthy right now" is the only question.
Build an advanced page#
Advanced pages are built from the Status Pages section and are available on Pro and Enterprise.
Components and groups. Sort monitors into groups such as API, Database, and Background Jobs, reorderable by drag and drop. One banner at the top shows the worst state across everything: Operational, Degraded, Partial Outage, Major Outage, or Maintenance.
Incidents. Declare them by hand with a status, impact, affected components, and timestamped updates, or let Drumbeats bridge monitor incidents automatically. They move through investigating, identified, monitoring, resolved.
Maintenance windows. Schedule ahead with a title, message, start and end time, and affected components. Upcoming windows appear publicly so nobody files a ticket about planned work.
Branding. Accent colour, default theme (auto, light, or dark), and a logo and favicon in PNG, JPEG, or WebP on Pro and Enterprise.
Feeds. Every advanced page publishes RSS and Atom:
https://api.drumbeats.io/v1/public/pages/<slug>/feed.xml
https://api.drumbeats.io/v1/public/pages/<slug>/feed.atomhttps://api.drumbeats.io/v1/public/pages/<slug>/feed.xml
https://api.drumbeats.io/v1/public/pages/<slug>/feed.atomThe Settings tab changes the name, slug, description, published state, and whether search engines are asked to skip it. An unpublished page returns 404.
What happens when a monitor goes down#
The status page reflects it automatically. A simple page flips its badge and, if incidents are shown, adds the outage to the history. An advanced page moves the affected component and recalculates the overall banner to the worst state across all components.
Nothing about this is manual, which is the point. The page is right without anyone remembering to update it during the incident.
Recovery is the same in reverse. The success ping that resolves the incident also clears the public page.
Keep the wrong things off it#
Three things do not belong on a status page. A monitor whose name or description leaks internal architecture. A monitor whose incident details would expose customer data or internal hostnames. And anything you would not want a competitor reading, since these pages are indexed by default.
Write display names for the audience, not for yourself. "Nightly backup" beats "JOB_CRON backup.sh".
Next#
Subscriptions to let visitors get email updates. Custom domains to serve a page from your own hostname. Incidents for the model behind the public history.