> ## Documentation Index
> Fetch the complete documentation index at: https://docs.oddspapi.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Reliability & Operations - Uptime, Status & Incident Response

> How OddsPapi delivers reliable realtime data for trading: redundant architecture, live status page, recovery design, support response, and incident handling.

OddsPapi is built for teams that trade on the feed, so reliability is a first-class concern. This page explains how the platform is designed to stay available, how to monitor it, and how to reach us when something goes wrong.

<Info>
  Specific uptime targets, support response times, and remedies are defined per agreement for B2B customers. Contact [contact@oddspapi.io](mailto:contact@oddspapi.io) to discuss SLA terms for your use case.
</Info>

***

## Live status & incident history

Real-time platform status, ongoing incidents, and historical uptime are published on our status page:

<Card title="OddsPapi Status Page" icon="signal" href="https://oddspapi-v5.instatus.com">
  Live availability, incident reports, and uptime history — subscribe for updates.
</Card>

Subscribe on the status page to be notified of incidents and scheduled maintenance.

***

## Architecture for availability

The platform is designed so that no single failure should interrupt your data flow:

* **WebSocket-first delivery** — a persistent gateway streams updates with minimal latency, avoiding the overhead and gaps of REST polling.
* **REST + WebSocket redundancy** — REST snapshots and the realtime stream are independent paths to the same data. If the stream drops, REST keeps your state current.
* **Resume & replay** — after a brief disconnect, clients resume from their last cursor and replay missed updates without a full refresh. See [Resume & Replay](/websocket/resume-replay).
* **Deterministic recovery** — when replay isn't possible, the gateway emits `snapshot_required` so clients rebuild state from a fast REST snapshot. Recovery is an explicit, designed path — not an error state.

***

## Designed for trading-grade failover

Recovery is bounded and predictable rather than best-effort:

* The gateway buffers a replay window (`resumeWindowMs`) so short interruptions resume with **no data loss**.
* If your cursor falls outside that window, a single REST snapshot restores full state in one call.
* Bookmaker connectivity is surfaced explicitly via the `staleOdds` flag, so you always know when a price may no longer be current.

This means worst-case recovery is a **fast, well-defined REST snapshot**, not an open-ended outage. See [Resume & Replay](/websocket/resume-replay) for the full recovery flow.

***

## Monitoring & operational responsibility

OddsPapi gives you the signals to operate safely; your client should act on them:

* Track the `staleOdds` flag per bookmaker before trading on a price.
* Handle `snapshot_required` and reconnect logic (see the [Resume & Replay](/websocket/resume-replay) template).
* Respect [rate limits](/api-reference/rate-limits) and [WebSocket connection limits](/websocket/overview); contact support to raise limits for distributed systems.
* Watch the status page for platform-level incidents.

***

## Support & incident response

| Channel                                           | Use for                                               |
| ------------------------------------------------- | ----------------------------------------------------- |
| [support@oddspapi.io](mailto:support@oddspapi.io) | Technical support, integration help, incident reports |
| [contact@oddspapi.io](mailto:contact@oddspapi.io) | API access, SLA terms, raising limits                 |
| [Status page](https://oddspapi-v5.instatus.com)   | Live availability and incident updates                |

When reporting an issue, include your `apiKey` group, affected channels or endpoints, timestamps (UTC), and any `serverEpoch` / `entryId` values — these let us trace your session quickly.