I started with a deceptively simple question: if I want to act just before a horse race starts, what time should I count down to?

The printed schedule seems like the obvious answer. When a race is delayed, a new start time should replace it. A program can then wait until the chosen moment, check that betting is still open, and act.

That is the tidy version. The live data showed something much less tidy.

I followed the start-time and betting-status messages over five race days. The analysis included 111 Swedish races whose real off followed their printed schedule. The median was already 54 seconds late without an earlier update. At the 90th percentile, that silent drift was 5.1 minutes.

For the most delayed races, the system often learned the corrected start only after the horses had already left.

Following one delayed race

The first figure follows race 8 at Romme on May 26, 2026. It was scheduled for 20:56 but actually started at 21:14:06, just over 18 minutes late.

Figure 1

Known start time through an 18-minute silent delay

The latest known start for one delayed race counts down to zero at the printed schedule, then falls through an 18-minute red blind region while the betting pool remains open.

The black line is the lead to the latest start known at each moment. It reaches zero at the printed 20:56 schedule, falls to roughly −18 minutes by the real off at 21:14:06, and jumps when the corrected final timestamp arrives about four seconds later. The definitive status signal follows at +8.9 seconds. The green ribbon shows that the pool remained bettable throughout the blind interval.

The black line represents the race’s believed lead time: the latest start known at that moment minus the current time. Before 20:56, the line counts down toward zero as expected. At 20:56 it reaches zero, but the race does not start and no replacement time arrives.

The line then falls into the red area. A negative value means that the latest known start is now in the past. The program knows that the pool is still open, but it has no future start to count down to. I call this interval flying blind.

For this race, the blind period lasted 18.2 minutes. The green strip across the top is important: betting remained open throughout it. There was plenty of clock time in which a bet could theoretically have been placed, but no reliable timestamp said when that window would end.

What happened at the real start

The second figure zooms in on the few seconds around the real start. The horses left at 21:14:06. The definitive race → ongoing status signal arrived 8.9 seconds later.

Betting closed in that same instant.

Figure 2

Signals arriving after the real start

Endgame around the real off. Betting remains open through the start, then the definitive status signal and betting close arrive together 8.9 seconds later.

Zero is the real off. The corrected final timestamp first appears at about +4 seconds, already too late to become a future target. The pool remains green and bettable until the +8.9-second mark, when the definitive race-status signal and betting close arrive together. The entire interval is after the horses have started, leaving zero seconds in which to act on that signal.

So the sequence was:

  1. The scheduled start passed.
  2. Betting stayed open for another 18 minutes.
  3. The horses started without a new future start time being announced.
  4. The definitive status confirmation and the betting close arrived together, 8.9 seconds after the horses had left.

This was not a slow reaction inside my program. The messages were applied in well under a second after they arrived. The missing time was upstream: there was no useful start announcement to react to.

There are two related messages in the data. The corrected final timestamp was first received about four seconds after the real off. That was already too late to serve as a future target. The definitive race-status signal and pool close followed at +8.9 seconds. The comparison figure below retains both events.

All 12 races with at least five blind minutes ended without notice

From 25 to 29 May 2026, 12 races spent at least five minutes flying blind. Three of the 12 received an earlier forward re-time, but every race still ended with a no-notice final start. Across all 111 races whose off followed the printed schedule, the median blind drift was 54 seconds and the 90th percentile was 5.1 minutes.

Figure 3

Twelve races with at least five minutes flying blind

Twelve delayed races shown as schedule, announced re-time, final timestamp, and betting-close lanes around each real off.

Each race has a reference lane followed by one lane for every distinct start time announced. Grey crosses are printed schedules. Filled dots show when an update arrived; open rings show the time it announced. Green means at least 60 seconds of forward notice, red means no notice, and purple runs from receipt of the final timestamp to betting close. The nonlinear axis compresses pre-off minutes and expands post-off seconds, keeping long schedule drift and the closing events visible together.

The black line at zero is the real off. On each reference lane, the red dot shows when the final-off timestamp was received and the purple dot shows when betting closed. The purple interval is useful timing evidence, but it is not a valid betting window: it occurs after the horses have already left.

Three races did receive an early replacement time. Those are the green lines. But all three slipped again and ended with a final start that had no advance notice.

The other nine races never received a useful forward update at all. Their best notice was negative: the corrected time arrived three to seven seconds after the horses had already left.

That made the result surprisingly consistent. Every one of the 12 races ended with a no-notice final start, even though the length of the delay ranged from about five to 23 minutes.

Why a countdown cannot solve this

A countdown-based strategy needs a future target. In simplified form, its rule looks like this:

act when the known start is close and betting is still open

During a silent delay, those two conditions never overlap in a useful way. Before the scheduled time, the countdown works but points to the wrong start. After the scheduled time, its target is already in the past. When the corrected time finally arrives, the race has started and the pool is closing.

Changing the lead time does not fix that structure. Nor does polling more often. The problem is not choosing the perfect countdown; it is that there may be no trustworthy future time to count down to.

This leaves two honest options:

  • Treat a stale schedule as a reason to skip the race.
  • Build a separate strategy around observable live state, such as the pool still being open and a start-status message arriving, rather than pretending to know the future start.

The first option is safer. The second may be useful, but it is a different decision rule with different risks. What should not happen is silently inventing a new start time from the current clock.

What I took from it

I expected delayed races to be a latency problem: get the update faster, react faster, and leave a little more safety margin.

Instead, the difficult part was the absence of an update. The printed schedule was not a precise start anchor even for ordinary races, and the largest delays were not reliably repaired by a new forward-looking time.

The sample is small—111 races whose off followed schedule over five days—so the 9-of-12 split should not be treated as a long-run prevalence estimate. A longer observation window is needed for that. But one operational conclusion does not need a prevalence estimate: a system that requires an accurate countdown must be designed for the case where that countdown does not exist.

The safer lesson is simple: when the only start time you know is already in the past, admit that you do not know when the race will begin—unless you are there to see it.

The three standalone figures were generated from the same canonical point-in-time data reconstruction used for this analysis.