Current component check
This browser requests the public health endpoint when the page opens. The result is a point-in-time dependency check—not measured uptime, historical availability, or a contractual SLA.
Waiting for a fresh response from /healthz.
Current public contract
Stats API publishes 11 implemented operations for service health, coverage, competitions, seasons, teams, fixtures, and full-time results. The OpenAPI document is the executable source of truth.
OpenFootball football.json is the only enabled data source. It is a community-maintained CC0 historical dataset, not a contracted live feed. The separate 35-operation coverage map is a roadmap and does not make live scores, players, xG, lineups, injuries, or odds available.
Release notes
| Date | Milestone | Verified boundary |
|---|---|---|
| 28 Jul 2026 | Public-preview foundation | Versioned football API contract, stable Stats API IDs, cache-first reads, account dashboard, usage controls, source ledger, agent-readable docs, blog, FAQ, and public health checks. |
Feature flags can keep account, API, or billing capabilities paused independently. A release note records what the software supports; the current documentation, coverage response, and checkout state remain authoritative for what a customer can use now.
Service and incident history
No customer-impacting incidents recorded
No verified customer-impacting incident has been recorded in this public history since it began. This describes the contents of the record; it does not claim 100% uptime or prove that no unobserved interruption occurred.
This public history begins on 28 July 2026. It is prospective and does not attempt to reconstruct uptime or incidents before that date. Incidents are never inferred from a missing probe or backfilled without a verified record, and the absence of an incident entry is not a guarantee of uninterrupted uptime.
Confirmed customer-impacting incidents will use the states investigating, identified, monitoring, and resolved. A published entry includes a neutral incident ID, severity, affected public components, customer-visible impact, UTC start and recovery times, a high-level resolution, and customer-relevant follow-up actions.
Public entries are sanitized. They never include secrets or API key material, customer or account identifiers, raw request or webhook payloads, database records, private hostnames, internal listeners, filesystem paths, protected co-tenant details, or exploitable security steps.
The machine-readable health endpoint reports the current database, required-schema, and cache dependency state. It is an operational signal, not a contractual SLA or a substitute for an independent external monitor.
How API changes are recorded
- Additive fields and operations appear in OpenAPI before examples or marketing copy rely on them.
- Breaking changes require a versioned contract or an announced migration path unless an urgent security, legal, or source-rights issue requires faster action.
- Corrections, reschedules, source limitations, and freshness boundaries remain visible in documentation rather than being described as guaranteed live data.
- Roadmap operations stay visibly separate from implemented operations until their data rights, ingestion, storage, tests, and public contract are complete.