A status page that isn't a $29/month subscription

A status page is one of those things that gets bought as a SaaS subscription almost reflexively, because historically it meant running a whole separate monitoring service just to answer “is it down for everyone or just me.” Railyard’s version exists because the platform already runs uptime checks on every app it hosts — the status page is a view onto data that already exists, not a new system to stand up.

What it actually shows

Create one from Status pages in the sidebar (admins only): a title, an address (https://app.railyard.run/status/<address>), and which apps to include, each with its own public-facing name — customers see “API” and “Dashboard,” never your internal app slugs.

Visitors get:

• An overall banner — operational, degraded, partial outage, or major outage, rolled up across every app on the page.
• One row per app with its live state: operational, degraded (2 or more of the last 5 checks failed), down, under maintenance, or sleeping.
• 90 days of daily uptime bars and the percentage, built from the same checks Railyard already runs — not a separate ping service with its own false-positive rate to tune.
• Current and recent incidents, the last 14 days of them.

The page refreshes every minute and follows the visitor’s own light/dark preference. A /status/<address>.json endpoint gives the same data — state, 90-day uptime, open incidents — for anything you want to build on top of it yourself.

Incidents that don’t require someone to remember to close them

This is the detail that matters more than the uptime bars: incidents open and resolve on their own, tied to the same checks — when an app goes down, an incident opens; when it comes back, the incident reflects that without a human having to log in and update a status field. You can still post your own incidents by hand (title, impact level, a status, a first update visitors see, and further updates as things change), which matters for the cases automation can’t know about — a degraded third-party dependency, a planned maintenance window — but the baseline case of “it went down and came back” needs zero manual intervention.

What it’s honest about not doing yet

Two real limits, stated plainly rather than discovered later: the page lives on Railyard’s own address, it can’t be served on your own domain yet. And its data comes entirely from uptime checks against your apps’ web addresses — a worker-only app with nothing listening on a port has nothing to check, so it has no meaningful row on a status page.

Why this is a smaller thing than it looks

The actual engineering behind a status page — uptime history, incident state machines, a public read-only view — already has to exist for the platform’s own monitoring and alerting to work. A dedicated status-page SaaS is selling access to data a PaaS already collects about your apps; here, the page is just that data made public on purpose.

Full reference: Status pages.