Odds Drop Alert Fires 4s Late, 39% Bet the Old Price

A latency audit of Croatian-facing sportsbook apps has found that in-play odds-change alerts arrive on punters' screens a median 4.1 seconds after the new price is already live on the operator's own trading feed — and that during those four seconds, roughly 39% of bets on the affected market are still being matched at the stale number. The finding comes from a 90-day instrumented study of 11 licensed operators, run between 3 February and 3 May 2025, and it puts a number on something most experienced bettors have long suspected: the alert you get is not the price you get.

The same audit logged 61,400 in-play price movements across football, basketball and tennis, and found the delay is not uniform. It is shortest on the most heavily traded markets and longest exactly where it hurts most — on the secondary markets, the corners, the cards, the next-goalscorer lines that casual players gravitate toward because the main markets feel picked over.

What the 4.1 seconds actually measures

The methodology matters here, because "latency" gets used loosely. The audit distinguished four separate timestamps that bettors tend to collapse into one:

• T0 — feed update: the moment the operator's trading partner (or in-house desk) publishes a revised price to the operator's backend.
• T1 — API propagation: the moment that price is queryable through the operator's public odds endpoint.
• T2 — client render: the moment the price is painted on the app or web client after the user's next poll or push update.
• T3 — alert delivery: the moment the push notification or in-app banner announcing the change actually reaches the device.

The 4.1-second median is T3 minus T0. That is the full journey, not a single hop. Broken down, the median T1−T0 was 380ms, T2−T1 was 1.9s (dominated by polling intervals), and T3−T2 was 1.8s (dominated by push infrastructure and, on some devices, OS-level notification batching).

The distinction is not academic. An operator can push the T1−T0 number down to near zero and still leave you staring at a four-second-old price, because the bottleneck sits in the client and the notification layer, not the trading feed. Several of the operators audited do exactly this in their marketing — "real-time odds" is a claim about T1, not about what you see.

Where the 39% comes from

The 39% figure is the share of matched stakes on a changed market that executed at the pre-change price during the four-second window. It is not 39% of all bets, and it is not 39% of bettors — it is stake-weighted, across the 61,400 logged movements, counting only markets where a change occurred and at least one bet was matched within the window.

The distribution is skewed. On main football markets (1X2, over/under 2.5), the stale-match share was 22%. On the long tail — corners, bookings, player shots on target — it was 54%. That gap is the whole story: the slower the alert and the thinner the market, the more likely you are transacting on a number that no longer exists.

There is a second-order effect worth naming. In 8.3% of the logged movements, the price moved against the bettor and the bet still matched at the old, better number. In those cases the operator, not the punter, ate the difference. That is the part nobody complains about. The complaints — and the disputes — cluster in the 6.1% of cases where the price moved in the bettor's favour and the bet was either rejected, repriced, or voided under a "palpable error" clause.

Why Croatia sees this more acutely than some markets

Croatia's online betting market has a structural feature that amplifies latency: a large share of traffic goes through a relatively small number of licensed operators, and a meaningful slice of that traffic runs over mobile networks rather than fixed broadband, particularly along the coast during the summer season when tourist density pushes cell load up.

The audit recorded median T3−T2 of 1.8s nationally but 2.6s on mobile connections in Split-Dalmatia and Dubrovnik-Neretva counties during July-equivalent load simulations. Push delivery on congested cells is simply slower. An operator cannot fix that from its side, and it is one reason the "just use a faster app" advice is only partly useful.

Regulatory context matters too. Under the Croatian gambling framework administered by the Ministry of Finance's gambling division, operators are required to display the odds applicable at the time of bet acceptance, and the accepted price is the contractual one. In practice this means the stale price you saw is usually the price you are entitled to — which is good for the bettor in the 8.3% of cases where the move helped, and the source of most friction in the 6.1% where it did not. The rules are not obviously broken. The user experience around them is.

The three failure patterns

Across the 90 days, the stale-price disputes fell into three recognisable patterns:

1. The notification that arrives after the goal. In football, the highest-frequency trigger for a price change is a goal, a red card, or a penalty award. These events produce feed updates in under a second. The alert about the resulting price change, however, competes with the user's own reaction time. If you are watching the stream, you already know. If you are not — if you are on a stats app, or following text commentary — the alert is your first signal, and it is four seconds behind the feed and often ten or more behind the event.

2. The repricing at acceptance. A bettor taps a price, the bet goes to the server, and comes back at a different number with an "accept changes?" prompt. The audit found this happened on 11.4% of in-play bets on volatile markets. Of those, the repriced number was worse for the bettor 71% of the time. This is not necessarily misconduct — the price genuinely moved — but it is a direct consequence of the same latency, just handled at the server rather than the client.

3. The void after the fact. Less common (0.4% of in-play bets in the sample) but the most damaging to trust: a bet accepted at a stale price, settled normally, then voided hours later under an error clause. These are rare and usually defensible on the operator's side, but they are the cases that generate the forum threads and the regulator complaints.

What the numbers say about operator behaviour

The audit split the 11 operators into three rough tiers by median alert latency. The spread is wide enough to be a genuine differentiator, and narrow enough that no operator is dramatically better than the field.

Tier	Median T3−T0	Stale-match share	Operators
Fast	2.4s	27%	3
Mid	4.1s	39%	5
Slow	7.8s	51%	3

The fast tier is not necessarily more honest. Two of the three fast operators achieve their number by reducing the number of alerts they send — they batch price changes and notify less often, which lowers measured latency on the alerts that do fire but leaves more changes unannounced. That is a legitimate trade-off, but it means "fastest alerts" and "most alerts" are different products, and the marketing rarely distinguishes them.

The slow tier is more interesting. All three slow operators run their in-play pricing through third-party feeds with less aggressive infrastructure, and two of them are the same operators that advertise "instant odds updates" most heavily. The audit cannot say whether that is deliberate. It can say the advertised claim and the measured T3−T0 do not match.

The 1.8-second notification tax

The single largest controllable component is T3−T2, the notification delivery leg, at a median 1.8 seconds. This is where operators have the most room to improve and the least incentive to, because a faster alert mostly benefits the bettor — it lets you act before the price you saw disappears. An operator that cuts its alert latency is, in effect, giving away a small edge it currently holds.

Some of that 1.8s is not the operator's fault. iOS and Android both batch and throttle push notifications, and a bettor with 40 apps installed is not getting sub-second delivery on any of them. But 1.8s is also well above what a well-run push pipeline should deliver, and the audit found operators using the same push vendor with latency spreads of nearly 3 seconds, which points to configuration and priority handling rather than infrastructure limits.

There is a cheaper fix that several operators have not taken: render the price change in the client before the push arrives. If the app is open, a websocket or a shorter poll interval would cut T2−T1 from 1.9s to well under half a second, and the alert becomes a secondary signal rather than the primary one. The audit found only 2 of 11 operators using a persistent connection on their in-play screen. The rest still poll.

What a bettor can actually do with this

The practical takeaways are unglamorous but real.

Treat alerts as confirmation, not as a signal. If the alert is your first knowledge of a price move, you are already 4 seconds behind. If you are actively trading an in-play market, keep the market screen open rather than relying on notifications — the render lag is measurable but smaller than the alert lag.

Know which markets are slow. The 54% stale-match share on secondary markets is the number to remember. If you are betting corners or cards in-play, assume the price you see has a better-than-even chance of being stale, and expect repricing at acceptance. The main markets at 22% are meaningfully tighter.

Check the repricing prompt before you accept. The 11.4% repricing rate on volatile markets means this is not a rare event. The prompt exists precisely because the server knows the price moved. Reading it costs you a second and occasionally saves you a bad fill.

Watch the settlement, not just the acceptance. The 0.4% void rate is small, but if you are betting volume on volatile markets, you will hit it eventually. Know which operators in your rotation have a history of post-settlement voids and weight your stake accordingly.

None of this is a strategy for beating the market. It is a strategy for not losing to infrastructure.

The responsible-gambling footnote that is not a footnote

There is a version of this article that treats latency as a pure consumer-protection issue, and it mostly is. But it is worth being honest about the other direction: a bettor who is chasing a live market, refreshing for a faster alert, and treating a four-second window as an opportunity is a bettor who is playing faster than they intended. In-play betting is the format most associated with loss of control, precisely because the loop is short and the feedback is immediate. A slower alert is annoying. A faster one is not automatically good for you. The Croatian Institute for Public Health's problem-gambling resources and the operator-level self-exclusion register exist for the cases where the loop gets too tight, and the fact that latency is a real grievance does not make speed a virtue.

The question the audit leaves open

The 4.1-second median is a measurement, not a verdict. What it does not establish is whether the delay is a cost of doing business that operators would fix if pushed, or a small structural advantage they have no reason to give up. The fast tier shows it can be done. The fast tier also shows that "done" sometimes means fewer alerts rather than quicker ones, which is a different product wearing the same label.

So the open question is not whether operators can cut the alert lag — two of them already have, at least on paper. It is whether a market where the punter is systematically four seconds behind the price, and where the regulator's rulebook is written around acceptance rather than around notification, has any mechanism that would make the lag a competitive problem rather than a tolerated one. On the current evidence, the answer is that the mechanism is the bettor's attention, and that attention is the one input the audit did not measure.