Status pages and badges
A public page showing the state of the monitors you choose to publish, plus an SVG badge for a README. It exists so that during an outage the people affected can answer "is it you or is it me" without opening a ticket, and so that the answer does not leak your internal hostnames while doing it.
Turning one on
- Status pages need Pro or above.
- Open Settings and set a status page slug. 3 to 40 characters, lowercase letters, digits and hyphens, starting and ending alphanumeric. This becomes the URL, so pick the company name rather than an internal project codename.text
https://pulsewatcher.vercel.app/status/acme
- Open each monitor you want published and turn on the status page flag. Nothing is published by default. A monitor is on the page because you decided it should be.
- Optionally turn on latency for that monitor. It is a separate switch, because publishing "up" and publishing "up, averaging 2.4 seconds" are different decisions.
- Confirm it worked: open the URL in a private window, signed out. You should see exactly the monitors you flagged and nothing else. If you see a 404, the slug is not set.
What a visitor can see
| Visible | Notes |
|---|---|
| Monitor name | As you named it. Rename anything you would not want a customer reading. |
| Current state | Up, down, or degraded. |
| 90 days of uptime history | One bar per day, from the daily rollup. |
| Average latency | Only when you turn it on for that monitor. |
| Published incidents | Title, and the text you wrote. Nothing else. |
What a visitor cannot see
These are enforced in the public route rather than filtered in the page, and a test fails the build if the route starts selecting any of them.
| Withheld | How |
|---|---|
| The checked URL | Never sent to the public endpoint at all. |
| Error messages and status codes | A visitor sees down, not "connection refused to 10.0.4.12". |
| Log excerpts and stack traces | The public route does not read those columns. |
| Ping tokens, metrics, exit codes | Never exposed. |
| Monitors you did not publish | Only monitors flagged for the status page are returned. |
| Incident evidence | The published body comes from curated text you wrote, not from raw diagnostic fields. |
The one thing you control entirely is the monitor name, because that is published verbatim. Checkout API is fine. db-prod-04 replica lag (Acme migration) is not.
Publishing an incident
An incident opens automatically when a monitor goes down, and stays private unless you publish it. What appears publicly is the title and the text you wrote, never the diagnostic detail attached to the incident. You can also open a manual incident for something PulseWatch cannot see, such as a scheduled migration.
Badges
An SVG showing one monitor's current state. The monitor must be flagged for the status page: a badge for an unpublished monitor returns 404, so a badge cannot become a side channel around your publishing decisions.
 <!-- with a shorter label -->  <!-- linked to the status page --> [](https://pulsewatcher.vercel.app/status/acme)
| Parameter | Effect |
|---|---|
| label | Replaces the monitor name on the left of the badge. Up to 40 characters. Useful when the monitor name is longer than a README wants. |
Badges are cached for 5 minutes, which is also how stale a badge can be. GitHub proxies images through its own cache on top of that, so a README badge is a rough indicator rather than a live dashboard. Point it at the status page for the real answer.
Variations
Customer-facing page
Publish the two or three endpoints customers actually depend on. Turn latency on. Rename them to the product names your customers use.
Internal page for another team
Publish the shared services, leave latency off, and use the incident text to say what the impact is rather than what the cause is.
Open source project
One published uptime monitor for the public API, one badge in the README linking to the status page.
Nothing published
A perfectly good configuration. Set no slug and every monitor stays private. The feature costs nothing when unused.
What can go wrong
The status URL returns 404
No slug is set on the account, or the slug in the URL does not match. Slugs are lowercased.
A monitor is missing from the page
Its status page flag is off. That flag is per monitor and defaults to off, so a monitor added later does not appear until you publish it.
The badge shows a stale state
Five minutes of caching on our side, plus whatever your host adds. GitHub's image proxy is usually the larger part.
The badge returns 404
The monitor is not published. Turn on its status page flag first.
An internal hostname is visible
It is in the monitor name, which is the one field published verbatim. Rename the monitor.
Downgrading to Free
The status page and badges stop serving. Nothing is deleted, and upgrading restores them with the same slug.