HazardNet system status

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.

Right now

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.

Derived 2026-09-17 21:42 UTC by scripts/build_freshness_artifact.mjs. 3 of 4 sources within their SLO.

Each data source this deployment ships, its state, its age and the SLO it is measured against.
SourceStateAgeSLOLatest data
Forecast ingest run (backend/data/forecasts/manifest.json)backend/data/forecasts/manifest.jsonWithin SLO45.7 h192 h2026-09-16
Website forecast snapshot (frontend/public/data/forecasts-latest.json)frontend/public/data/forecasts-latest.jsonWithin SLO45.7 h192 h2026-09-16
Alert snapshot (frontend/public/data/alerts-latest.json)frontend/public/data/alerts-latest.jsonWithin SLO0.6 h48 h2026-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.jsonUnknown2 h

Coverage of the current run

60 of 64 districts have a row for at least one horizon, from 74 produced district/horizon units — coverage status partial.

Model provenance

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.

Last site-health probe

No probe result has been published to this checkout, so the live-surface checks are unknown here — not passing.

What this page is not saying

  • model_version is null: the ingest pipeline does not stamp one yet, so nothing can be auto-published above WATCH and the alert engine records publication_blocked instead of issuing an alert (PRODUCT_SPEC §1.6).
  • the forecast run reports coverage status "partial": 60 of 64 districts have a row for at least one horizon.
  • the run did not report which districts are missing, so this page cannot name them — absent is reported as absent, not as "none".
  • 74 assessed district/horizon rows produced no published alert: every one was withheld by the review gate rather than dropped silently.
  • no site-health probe result is committed here, so the live-surface checks are unknown on this page — check the Site Health Probe workflow for the current run.
  • forecast ages are measured from the date-granular prediction_date (UTC midnight), so they carry up to ±24 h of granularity.

How this page is produced

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.

What the states mean

  • Within SLO — the source is present and its age is inside the SLO that applies to it: 192 hours for the forecast data, 48 hours for the alert snapshot, 2 hours for the probe result.
  • Past SLO — the source is present but older than its SLO. The age and the SLO are both printed so the gap can be read directly.
  • Checks failing — the last site-health probe run reported at least one failed check; the checks table names them.
  • No data — the artifact the source describes is not present in this deployment at all. No age is printed, because there is nothing to age.
  • Unknown — the artifact could not be read, or it does not carry the timestamp the age would need. Unknown is a distinct state from No data on purpose: one means the file is missing, the other means we cannot tell.

What this page deliberately does not claim

  • It is not an uptime or availability report. No uptime history is kept and no percentage is computed here; the site-health probe reports an outcome per check, per run, and that is what it says.
  • It is not a live probe. A source can be Within SLO here while the deployed site is failing its checks — the probe row, not the freshness rows, is the live-surface signal.
  • It does not name missing districts when the run did not report them. The coverage stamp says how many districts the run covered; if the run did not list which ones are absent, this page says so rather than inferring them.
  • It does not describe a model version that does not exist. While the ingest pipeline does not stamp a model_version, the provenance row says Not stamped, and the alert engine's publication gate stays closed for everything above WATCH.
  • It is not an official warning service. Read the methodology page for scope, and heed the warnings issued by BMD, FFWC, DDM and your local administration.

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.

Questions and answers

How often is this page updated?

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.

Why does the model version say Not stamped?

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.

The alert list is empty — is that an error?

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.

Does Within SLO mean the site is up?

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.

Content reviewed 2026-09-18. HazardNet is decision support, not an official warning service — see the methodology for scope and limitations.

Loading the interactive HazardNet application…