What to do when your Pinnacle API cursor is gone

The fix for a lost Pinnacle API cursor is short: stop the delta loop, take one full board read, store the new cursor together with the snapshot it produced, and resume delta polling from there. The overlap between your last good state and the full read is absorbed by the deduplication rule you already run. What matters is everything around that fix: noticing the loss quickly and making it rare.

How cursors get lost

The cursor is a position in the feed: the last value from the previous response, sent back as since on the next one. Losing it usually means losing the store it lived in. A Redis flush, a dropped volume, a deploy that pointed the poller at an empty database, or a process that crashed between receiving a response and persisting its cursor all produce the same result.

A subtler loss is the stale cursor: the value exists but no longer matches anything the API recognizes, so every delta call behaves like a first call. Treat both cases the same way.

Notice it fast

Two signals catch a cursor problem. At boot, a poller that finds no stored cursor should say so loudly instead of quietly starting over, because a silent full read looks healthy in the logs while multiplying your request volume. In steady state, the cursor progress metric does the watching: alert when the last value has not changed for 30 minutes while events on the board are in play, as the pipeline monitoring guide states, checked 2026-09-30.

The recovery procedure

Run it in order:

1. Stop the delta loop. Polling with a missing or broken cursor only spends requests.
2. Take one full board read per sport and phase you cover. The documented contrast is 1,522 events for a full prematch soccer board against 7 changed events in the delta after it, which is exactly why full reads belong to recovery and not to steady state.
3. Persist the new cursor atomically with the snapshot it produced, so the pair survives the next crash together.
4. Resume the delta loop from that cursor.

Your history tables survive the overlap untouched. The rule from the storage guide, insert a row only when a selection's price differs from the latest row you hold, means the full read writes only what genuinely changed while you were down. What you cannot recover is the path between the last good poll and the restart. The storage guide is blunt about it: gaps stay gaps, so record the outage in a separate table and let queries tell a quiet market from a missing one.

Make the next loss boring

Three habits turn cursor loss from an incident into a footnote. Persist the cursor in the same transaction as the state it produced, so you never hold one without the other. Keep a single writer for the cursor, because two pollers advancing one cursor in different places is a slower kind of loss. And rehearse the recovery: the integration guide reserves full snapshots for first boot and disaster recovery, and a recovery you have never run is a recovery you only hope works.

A cursor is cheap state. Treat it like state: store it with care, watch it move, and know the four steps before the day you need them.