This page is built from the artifacts the deployment ships — the forecast snapshot, the ingest manifest, the alert snapshot and the last site-health probe result — not from a live probe of the running services. It states the age of each source against the SLO it is measured against, the coverage of the current run, the model provenance, and what the last probe run found. Where a value is unknown, it says unknown.
A derived statement about the committed data artifacts this deployment ships. It is not a live probe and it does not measure the running services — the site-health probe result it carries is whatever the last scheduled run published.
| Source | State | Age | SLO | Latest data |
|---|---|---|---|---|
| Forecast ingest run (backend/data/forecasts/manifest.json)backend/data/forecasts/manifest.json | Within SLO | 45.7 h | 192 h | 2026-09-16 |
| Website forecast snapshot (frontend/public/data/forecasts-latest.json)frontend/public/data/forecasts-latest.json | Within SLO | 45.7 h | 192 h | 2026-09-16 |
| Alert snapshot (frontend/public/data/alerts-latest.json)frontend/public/data/alerts-latest.json | Within SLO | 0.6 h | 48 h | 2026-09-17 21:08 UTC |
| Site-health probe (data/site-health/latest.json, every 30 min on the default branch)no probe result has been published to this checkout yet — the status page reports the data it can see, and says so instead of assuming the site is healthydata/site-health/latest.json | Unknown | — | 2 h | — |
60 of 64 districts have a row for at least one horizon, from 74 produced district/horizon units — coverage status partial.
Not stamped. The ingest pipeline does not yet record a model_version on the rows it produces, so no number on this site claims one, and §1.6 of the product spec blocks automatic publication of anything above WATCH until one exists.
No probe result has been published to this checkout, so the live-surface checks are unknown here — not passing.
The numbers above are derived from four committed files: the website forecast snapshot (frontend/public/data/forecasts-latest.json), the ingest run manifest (backend/data/forecasts/manifest.json), the alert snapshot (frontend/public/data/alerts-latest.json) and, when one has been published, the site-health probe result (data/site-health/latest.json). A build script (scripts/build_freshness_artifact.mjs) turns them into frontend/public/data/freshness.json, and this page renders that artifact — the same file a script or a monitoring system can read.
The derived timestamp printed above each table is when that artifact was produced. It moves when the pipeline commits new data, when the probe commits a new result, and when the site is rebuilt.
Within SLO on this page describes the committed data files the deployment ships, not the services that serve them. For the live surface — the homepage, deep links, security headers, the sitemap and the forecast endpoint — read the last site-health probe result in the table above or the Site Health Probe workflow run it links to.
Whenever the data it describes is committed: the scheduled forecast pipeline commits a new snapshot (and therefore a new derived artifact) when it runs, the site-health probe commits its result every 30 minutes on the default branch, and every deployment rebuilds the page from whatever artifact is committed at that commit. The derived timestamp printed with the tables is the authoritative answer for the copy you are reading.
Because the ingest pipeline does not currently record a model_version on the rows it publishes, and this page will not print one it cannot prove. The same absence is why nothing above the WATCH level can be published automatically yet: the product spec requires a model version on a published alert, and the engine records that as a blocker instead of issuing one.
No. The alert engine assessed the current run's rows and published none of them, because none of them had the model provenance a published alert requires. The count of assessed rows that produced no published alert is stated in the notes above, so an empty list is visible as a state rather than as a silent absence.
No. Within SLO is a statement about the age of a data file against its threshold. Whether the deployed site serves its pages, its headers and its API is what the site-health probe checks, and its result is reported separately above.
Loading the interactive HazardNet application…