Orbit Status Page

A status page is a public, no-login URL that shows whether your project is up, how it has performed recently, and what you have deployed. Turning it on also starts an uptime check that pings your project every minute, so you get monitoring as a side effect of publishing it.

Where the Status Page Settings Live

Open Orbit, click the project, and choose Status page under the Observability group in the project tab strip. The page is titled Public status page.

Turning It On

1. Switch on Enable public status page.
2. Choose a Public slug. This becomes part of the public URL, so pick something recognisable, such as your product name.
3. Optionally set a Ping path. It defaults to /.
4. Fill in the Page title and Tagline shown at the top of the public page.
5. Decide whether to Show recent deploys and Show recent incidents.
6. Click Save settings.

Once saved, the page shows a Live badge and confirms that your status page is published and pinging every minute. A link takes you to the public page so you can see what visitors see.

Slug Rules

The slug must be lowercase letters, digits and hyphens, up to 80 characters, and cannot start or end with a hyphen. Slugs are unique across all of Orbit, not just your account, so a common word may already be taken. If it is, saving returns a message saying the slug is already taken and you pick another.

Choose the slug carefully: it is the public address you will put in your documentation and your support replies, and changing it later breaks every link to it.

What Visitors See

The public page is built from the same data as your project's own tabs:

• Current status, from the most recent deployment: Operational, Building, Deploying, Queued, Awaiting Approval, Build Failed, Cancelled or Rolled Back.
• Uptime, computed over rolling 24 hour, 7 day and 30 day windows from the minute-by-minute checks.
• Recent deployments with a success rate, if you enabled that section.
• 30-day statistics: success rate, average build time and total deploys.
• Core Web Vitals, as p75 over the last 30 days, if you are collecting them.
• Incidents, drawn from annotations you have marked on the project timeline.

The page refreshes itself, so a customer who leaves it open during an incident sees it update without reloading.

Incidents Come From the Timeline

The incidents section is not a separate editor. It shows annotations of kind Incident from the project's Timeline, so the workflow during an outage is: mark an incident annotation, and it appears publicly.

That is deliberate. It means your internal timeline and your public communication stay in sync without anyone maintaining two records. See Orbit Timeline Annotations for how to write one.

The Uptime Check

Enabling the status page starts a check that fetches your project's production URL, at the ping path you set, once a minute. Each result is stored, and the uptime percentages on the public page are computed from those records.

Checks are kept for 90 days and older ones are trimmed automatically.

Choosing a Good Ping Path

The default / works for most projects. Two reasons to choose something else:

• Your home page is heavy. A lightweight path is a fairer and cheaper thing to poll once a minute.
• Your home page can be up while the app is broken. A cached static shell will happily return 200 while your API is down. A path such as /api/health that actually exercises the application tells the truth.

If you already have a health check configured for auto-rollback, using the same path here keeps both signals consistent. See Deploying Your Project for the health check settings.

Removing the Status Page

Click Remove page and confirm. The confirmation is explicit: all uptime history will be deleted.

That is worth pausing on. Removing the page is not a pause button. The check stops, the public URL stops working, and the accumulated uptime record goes with it. If you only want the page to be temporarily invisible, there is no hidden mode: consider whether switching the enable toggle off and leaving the configuration in place suits you better than removing it.

The slug is released when the page is removed, so someone else can claim it afterwards.

Practical Advice

Publish before you need it. A status page created during an outage is a status page nobody has bookmarked. Put the link in your footer, your documentation and your support signature while everything is fine.

Do not over-promise. The uptime figure on the page comes from a one-minute check against one path. It is honest monitoring, not a contractual SLA, and it should not be presented as one.

Keep the tagline short. It sits under the title on a page people open when they are already frustrated. One line saying what the service is, and nothing else.

Troubleshooting

Uptime shows 0% or is much lower than reality. The ping path is returning a non-2xx response. Open it in a private browser window: a redirect to a login page, a 404 from a path that no longer exists, or a geo-block are the usual causes.

The public URL 404s. The page is saved but the enable toggle is off, or the slug in your link does not match the one saved. Copy the link from the settings page.

The slug is rejected. It is taken, contains an invalid character, or starts or ends with a hyphen.

No vitals appear on the public page. Vitals come from the collector script on your site. See Orbit Web Vitals.

No incidents appear even though we had one. The annotation has to be of kind Incident, and the Show recent incidents switch has to be on.

Where To Go Next

• Orbit Timeline Annotations to publish incident updates.
• Orbit Webhooks to get notified before your customers do.
• Orbit Web Vitals for the performance figures shown publicly.