Every fault we have recorded, including the ones nobody outside would have noticed. Entries are added by hand and never removed.
This log begins 2026-07-21, the earliest event we can evidence from the repository and the monitors. It makes no claim about anything before that date — "no incidents" for a period we cannot support would be the kind of unearned assurance this service exists to avoid.
No customer-visible outage is recorded in that period, across 6 entries. Most of what follows is monitoring: the service was serving and our ability to see that it was serving had a hole in it. That is left visible rather than filtered out, because a log that showed only outages would say almost nothing true about this system.
monitoring · 4
the service was fine and our ability to see it was not
source · 1
an official source we cite went down or changed under us
prevented · 1
a latent fault that would have caused an outage, found and fixed first
Two source-change alerts fired for changes that had not happened
· monitoring · 5c28aa3
What a customer saw: None. No served value was affected.
What happened: Source-watch stored a sensor's fingerprint keyed by sensor id, with no record of which URL or filter produced it. A newly added sensor inherited a baseline left by a same-named sensor removed nine days earlier and reported the source as CHANGED on its first run. Separately, a Benin ministry page prints live download counters, so its content genuinely differed every few minutes.
How it was found: Reading the sweep output while adding twenty new sensors.
Closed by: A baseline now records the URL and the filter it was taken from and re-baselines instead of alerting when either moves; orphaned baselines are pruned. The Benin sensor strips the counters before hashing. Every repoint in the file's history had carried the same false alert.
An Iraqi ministry's certificate expired and took five citations unverifiable
· source · 98cbf60
What a customer saw: Values continued to be served with their citations. Five Iraqi citations could not be re-verified against their source while the certificate was expired, which the provenance record showed as BLOCKED rather than as confirmed.
What happened: The Let's Encrypt certificate for moj.gov.iq expired at 16:46:12 UTC. Nothing watched the certificates of the hosts we CITE — only our own — so the first sign was a bare TypeError from a fetch.
How it was found: By accident, from an unhandled fetch error.
Closed by: A new watcher checks the certificates of cited hosts and alerts only where a source is about to go dark and we have never captured it, since we cannot renew another government's certificate.
Certificate watch was blind to the origin certificate
· monitoring · 4ef132b
What a customer saw: None, but an expiring origin certificate would not have been seen.
What happened: The certificate monitor checked the public endpoint only. Because the fleet sits behind a proxy, it was reading the edge certificate and never the origin's, so an origin certificate could have expired unnoticed.
How it was found: Review after an unrelated certificate question.
Closed by: The watcher now checks the origin certificate as well as the edge.
The blind-sensor alert could not be delivered if Telegram was the outage
· monitoring · aae0e6e
What a customer saw: None.
What happened: Source-watch reported a sensor going blind only through Telegram. If Telegram was itself the thing failing, the alert about being unable to see would also be invisible — a monitor whose only failure report depends on the channel it is reporting about.
How it was found: Review of the alerting path.
Closed by: The blind-sensor path no longer depends solely on a successful Telegram send.
A restart at the wrong moment would have crash-looped the API
· prevented · 8623752
What a customer saw: None — found before it fired in production.
What happened: The service contacts the x402 facilitator during boot. The box has no IPv6 route, so that call could fail with ENETUNREACH and take the process down on startup, which systemd would then retry into a crash loop. The identical latent fault existed in the Zaronia API on the same box.
How it was found: Reading the boot path after an unrelated restart, not by an alert.
Closed by: NODE_OPTIONS=--dns-result-order=ipv4first on both services, and the 24 systemd units were copied into git so infrastructure changes are reviewable.
euroref.dev reported DOWN twice; it was never down
· monitoring
What a customer saw: None. The service answered throughout; the alerts were wrong.
What happened: The uptime monitor used a single 15-second request per host. The box's outbound network hiccuped twice, and a healthz timeout was recorded as the host being down. One of the failures coincided with an unrelated timeout to the Bazaar API in the same run, which is what showed the fault was our egress rather than the host.
How it was found: Telegram alert, contradicted by the sites being reachable by hand.
Closed by: The probe now retries three times before believing a failure, and an alert additionally requires two consecutive down runs. Fast process death is still caught instantly by systemd OnFailure, so debouncing costs nothing on the failure mode that matters.
Availability figures are on the status page, measured by us and scored against the probes that should have run. For measurement that is not ours, see the independent prober named there.