Skip to content
System status LIVE PROBES · REFRESH 30S

Every service, on the record. Checked by probes, never set by hand.

Live health for the detection and forecast pipelines, alert delivery, the public API and the app, with ninety days of measured uptime per service. Every state on this page was written by a probe that checked the service itself.

SIX SERVICES · 90-DAY HISTORY · EMAIL + RSS

Connecting
Fetching

Pulling latest service health…

READ FROM THE PROBES · NOT A HAND-SET RIBBON RSS
BACKDROP · ILLUSTRATION
Services LOADING…

Six services, ninety days each.

Every card is one service’s own probe: its state right now, the uptime it has measured, and a day-by-day bar. Hover a day for the check counts. Reconstructed days are marked, and never counted in the percentage.

Data freshness
 
Target: under 5 minutes
Availability
 
SLO 99.9%
Alert delivery
 
Delivery probes loading
Incidents LAST · 90 DAYS
— %
Clean operation
Zero customer-impacting incidents in the last 90 days.
Feed
How it is measured 6 QUESTIONS

What the probes can and cannot say.

Where each state comes from, how often it is checked, and what the page refuses to claim.

Where does this status come from?

From automated probes, never from a person. The detection and forecast pipelines are judged by the freshness of what they publish, the API and the app by a request to their health endpoints, and the ground-truth job reports on itself. The page reads those results straight from public storage and refreshes every 30 seconds.

How often is each service checked?

The API and the app are probed about once a minute. The detection pipeline is checked every two minutes, the ground-truth job reports every fifteen minutes, and the forecast pipeline is checked hourly. If a service has not written its status file in thirty minutes the page shows it as stale rather than healthy, because a probe that has stopped writing cannot vouch for anything.

What is the difference between measured and reconstructed days?

Measured days come from live probe samples and are the only days counted in the uptime percentage. Reconstructed days were rebuilt after the fact from the pipeline’s own output records, from before the probes existed. They fill in the bar and are labelled as reconstructed in the day tooltip, but they are never counted as uptime, and hours that could not be verified are shown as unknown rather than as up or down.

What availability does Hail Sentinel commit to?

The platform target is 99.9% availability per service, and each service card shows its error budget against that target over the measured window. A contractual commitment applies only to business agreements that include one; the free tier and trial accounts are provided on a reasonable-efforts basis. The terms of service set out the details.

Read the uptime terms
Why does a service show Pending or Stale?

Pending means the service has not published a status file yet, so there is nothing to show. Stale means its file exists but has not been written recently, so the last state cannot be trusted. Neither counts as healthy and neither counts as an outage: the page says what it can see and no more.

How do I get notified when something changes?

Subscribe with your email below to be told when a service changes state or maintenance is scheduled, and about nothing else. There is also an RSS feed of incidents for feed readers. Alerts about hail itself come from the app and are unaffected by this page.

Subscribe to status updates
Stay informed EMAIL · RSS

Hear it from the probes first.

One email when a service changes state or maintenance is scheduled. No product news, no marketing. RSS for feed readers.

WHAT YOU GET
State changes Degraded, outage, recovered
Maintenance Window and scope, ahead of time
Nothing else No product news, ever
BACKDROP · ILLUSTRATION