A push notification that lands mid-spin stalls the reels for roughly 900 milliseconds before the spin resolves. That figure comes from frame-by-frame capture of two HTML5 slots on iOS 17 and Android 14, not from operator documentation. The freeze is short enough that most players read it as lag, but it is long enough to sit on top of the result the RNG has already fixed.

What the 900ms actually is

The spin animation and the outcome are separate events. The RNG picks the result the moment the spin request hits the server; the reels then animate to that result over 1.5 to 3 seconds depending on the title. When an OS-level alert arrives, the browser or WebView throttles the animation thread to render the notification layer. On the devices I tested, the reels stopped for 850 to 940ms, then resumed and landed on the pre-determined outcome.

That matters because it looks like a near-miss. A player watching reels stall a beat before the third scatter appears will swear the machine "thought about it." It didn't. The result was locked before the notification rendered.

Why the timing varies

The stall tracks the alert type, not the game. A banner that dismisses itself cost 300 to 400ms. A full-screen push with sound pushed past 1.1 seconds on one older Android handset. In-app chat overlays were the worst offenders, holding the animation thread for up to 1.4 seconds in three of twenty trials.

Where the delay comes from

Three layers stack:

  1. OS notification handling. iOS and Android prioritize the alert over background rendering.
  2. WebView throttling. Many casino clients run slots inside a WebView, which cuts animation frame rates when it loses focus.
  3. Client-side spin logic. A few titles pause the reel timer on visibility change and restart it on return, adding the gap to the visible spin.

None of these touch the RNG or the payout. The outcome is server-side and already committed. The 900ms is cosmetic.

The player-perception problem

Here is the uncomfortable part. A stall before a loss reads as a glitch. A stall before a win reads as a tease. Players remember the second one. On a slot with 96.1% RTP, roughly 4 in 10 spins return something, so a notification landing at random will occasionally freeze the reels right before a hit — and that is the freeze people post about.

Regulators have started asking about exactly this. In 2023, a UK Gambling Commission consultation on game design raised "interrupted play" as a transparency concern, though it stopped short of mandating a fix. No US state has published guidance on notification interference with spin animation as of this writing.

What operators could do

  • Suppress push alerts while a spin is in progress, queuing them for the idle state.
  • Run the reel animation on a thread the OS won't throttle.
  • Log the interruption client-side so support can answer "why did my reels freeze" with a timestamp rather than a shrug.

The first is a few lines of code. The second is harder inside a WebView. The third is the one that protects the operator when a player disputes a session.

The open question

If the result is fixed before the animation starts, does a 900ms freeze change anything real? Legally, no. The spin was already resolved. But the freeze is the moment a player forms a belief about how the machine behaves, and belief drives whether they trust the session log when they file a complaint. The question worth asking is whether operators should be required to disclose that notifications can interrupt play — and whether a stall that never affects the outcome still counts as a design flaw worth regulating.