> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://docs.datafortennis.com/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.datafortennis.com/_mcp/server.

# Service status and observed uptime

> Read current API, WebSocket and source checks without confusing availability with data coverage.

Visit [status.datafortennis.com](https://status.datafortennis.com) for current
checks, measured history and automatically recorded incidents. Sign in and manage
your account at [console.datafortennis.com](https://console.datafortennis.com).

## What the monitors measure

| Component | Observation |
| --- | --- |
| Data API | Public liveness and readiness, expected unauthenticated denial, and authenticated live-route responses |
| ATP, WTA, ITF and Challenger API reads | A valid response from the corresponding observed-live filter; an empty list is valid |
| Live WebSocket reachability | Public ticket issuance, authentication, bootstrap and heartbeat |
| Validated event delivery | A persistent two-connection client with schema, cursor, replay and duplicate checks |
| Connection continuity | Unexpected physical closures remain visible even when the peer continues delivery |
| Source freshness | Successful source polling, evaluated independently for ATP, WTA, ITF and Challenger |

A source can be polling successfully while no match score changes. Conversely,
a connected WebSocket can serve stale data if a source stops updating. The page
separates these conditions. It does not certify complete tournament coverage,
every match lifecycle transition, point enrichment or prediction availability.
For supported adapter categories, see the [Live WebSocket quickstart](/start-here/live-web-socket-quickstart).

## Timing and history

Checks and page refresh run every minute. **Last updated at HH:mm UTC** is the
latest committed measurement, not the time you opened the page. Components without
current measurements for more than five minutes become **No data**.

The 7-day view uses two-hour intervals, 30 days uses eight-hour intervals and 90 days
uses daily intervals. Hover, focus or tap a segment for its UTC bounds, measured
status and observed/unknown duration. Gray portions have no measurements and are
excluded from observed uptime. A percentage is always qualified by the amount of
observed time; it is not a monthly contractual SLA. History begins when monitoring
starts, with no synthetic backfill. Under extreme state churn, only the latest 400
transitions per component are returned; omitted older periods remain unknown.

## Incidents and recovery

Normal failures and recovery require two consecutive minute checks. Unexpected
access, incoherent delivery and unexpected physical closures are recorded without
waiting for a second occurrence. Missing observations never count as recovery.
Incidents state the measured symptom and subsequent successful checks. They do
not automatically infer a network, server or provider cause, or claim that a root
cause has been permanently fixed.

A green connection check cannot override source delays or unknown observations.
If your client is affected while the page looks healthy, preserve the request ID,
UTC time, finite error code and last processed cursor. Never send credentials,
connection tickets, payloads containing private data or provider endpoints.
The status page shares the website hosting platform; independent external checks
and operator alerts continue to monitor failures outside that platform.