Poker Fold Button Grays Out 2 Seconds Before the River Card
Poker players on at least one real-money platform have reported a reproducible bug: the fold button turns gray and stops accepting input roughly 2 seconds before the river card is dealt, then reactivates once the card is on the felt. The claim is specific enough to test — a two-second lockout, timed to the final community card — and specific enough to worry about, because a button that goes dead before the last card is exactly the button a player might want to press after seeing it.
The reports surfaced in player forums and Discord servers over the past several weeks and were described to me by six players who say they encountered it across low- and mid-stakes no-limit hold'em tables. None of them could confirm whether the lockout is a deliberate feature, a client-side rendering artifact, or a server-side timing mismatch. The operator, which I'm not naming because the behavior is unconfirmed and the company has not responded to two written requests for comment, has not posted anything about it in its changelog or status page.
What follows is an attempt to separate what's verifiable from what's inference: how the timing was measured, why a two-second window matters more than it sounds, what the plausible technical explanations are, and what players can actually do about it in a market where the rules on software fairness are thinner than most people assume.
What the two-second window actually looks like
The behavior, as described and as I partially observed in screen recordings shared by two players, is consistent. With the action on you and the turn already dealt, the fold button is live and responsive. At some point in the animation sequence that precedes the river — before the card is revealed, before the burn card animation completes on the client — the fold button's state changes. It renders in a desaturated gray. Clicks do nothing. The cursor doesn't change to a pointer.
Then the river appears, and within a fraction of a second the button returns to its normal state and accepts input again.
One player, a $1/$2 regular in Pennsylvania who asked to be identified only by his screen name, "turncard," said he first noticed it in early March and initially assumed it was lag on his end. "I thought my mouse was dying," he said. He started recording his sessions and isolated eleven instances over roughly 4,000 hands — a rate of about one every 360 hands, though he cautioned that he only noticed the ones where he was actually considering a fold.
That frequency estimate is the weakest part of the picture. Players notice a dead button when they intend to use it; they don't notice it when they don't. The true rate could be higher or lower, and nobody has instrumented the client to find out. What's more solid is the timing: in the recordings I reviewed, the gap between the button graying out and the river appearing ran between 1.7 and 2.3 seconds, clustering near 2.0.
Why the timing is the interesting part
A dead button at a random moment is annoying. A dead button that reliably precedes the river by about two seconds is a different kind of problem, because it lands precisely in the window where a player's decision is most likely to change.
Consider the spot. You're facing a bet on the turn with a marginal holding — a flush draw that missed, a weak pair, an overcard plus a gutshot. You have a decision to make and you're using the time bank, or you're just thinking. The river is coming. If it bricks, you fold. If it completes your draw, you call or raise. The two seconds before the river is dealt is not dead time; it's the tail end of the decision window, and on some clients it's when the "check-fold" or "fold" input gets queued.
If the button is dead during that window, the practical effect depends on how the client handles late input. In most modern poker clients, an action you take is timestamped server-side, and an action that arrives after the deadline is treated as a fold or a check depending on the situation. A two-second lockout that ends when the river lands could, in principle, push a player's input past the server's cutoff — or it could be purely cosmetic, with the client simply refusing to register a click it would have accepted anyway.
I could not determine which. The players I spoke to said they had not been penalized in a way they could attribute to the bug — no hands where they were timed out and forced to fold against their will. But none of them had reviewed hand histories specifically looking for it, and the operator's hand history export doesn't include client-side input timestamps.
The technical explanations, ranked by plausibility
There are at least four candidate explanations, and they're not mutually exclusive.
Animation lockout. Many clients block input during the deal animation to prevent players from acting on a card before it's visually revealed. This is a legitimate design choice — it stops a player from folding "early" in a way that leaks information or creates an unfair edge. But a well-built client blocks input for the duration of the animation, not for two seconds before it. If the lockout is an animation guard, it's mistimed: it's starting too early, before the river animation begins.
Server-client clock drift. The client may be receiving an "action closed" signal from the server ahead of the actual deal, and rendering the button as disabled during that gap. If the server's deadline is set two seconds before the river deal — a plausible buffer to let the dealer process queued actions — then the client is faithfully showing a real state. The button isn't broken; the deadline is just earlier than players assume.
A pre-deal "no more action" state tied to the turn's close. In some game engines, once the turn betting round closes, the client enters a transitional state before the river. If the fold button's enabled state is bound to "betting round open" rather than "action available," it would gray out the moment the turn round closes, which is roughly when the river deal sequence begins. That would produce exactly the observed timing.
An actual defect in the input handler. The least interesting and hardest to rule out: a race condition, a stale event listener, a UI state machine that doesn't reset cleanly. Bugs like this are common in clients that ship frequent updates, and they tend to be intermittent — which fits the reports of roughly one occurrence per few hundred hands.
The third explanation is the one I'd bet on, and it has an uncomfortable implication. If the button is disabled because the client believes the betting round is closed, then the lockout isn't a bug at all in the operator's frame — it's the client correctly reflecting a rule. The question becomes whether the rule is the one players think they're playing under.
The rule players think they're playing under
In live poker, you can fold at any point before you've acted, and the dealer will take your cards. Online, the action is governed by a timer, and the timer's relationship to the deal is set by the operator. Most players assume the deadline is "when the next card is dealt" or "when the action closes," and in practice those are close enough that the distinction rarely matters.
A two-second pre-deal lockout makes the distinction matter. It means the effective deadline is earlier than the visual deadline. A player who waits to see the river before folding — which is a legitimate and common line, especially with a draw — is not just slow; they're past the cutoff. And because the button is gray rather than absent, the client is communicating "you can't do this" without explaining why.
That's the part that bothers the players I spoke to more than the lost hands, which they say have been few or none. "It's the not knowing," said a player who goes by "riverrat_88" and plays $0.50/$1 in New Jersey. "If the rule is you have to decide before the river, fine, tell me that. Don't gray out the button and let me sit there clicking it."
What the numbers say, and what they don't
The most concrete figure in this story is the one nobody has: the actual rate at which the lockout occurs, and the actual number of hands affected. The operator has that data. Players don't.
What players do have is hand histories, and hand histories are more useful than they look. A hand history records the action taken, the timestamp of the action, and the cards dealt. If a player folds on the turn in a hand where the river would have completed their draw, the history won't tell you whether the button was gray — but it will tell you the fold happened, and if enough players cross-reference their recordings against their histories, a pattern would emerge. None of the players I spoke to had done this systematically. Two said they'd started keeping a spreadsheet; neither had more than a few dozen entries.
There's a broader number worth keeping in mind. The American online poker market is small and fragmented — regulated interstate compacts in a handful of states, plus a long tail of offshore sites that serve U.S. players without a license. Oversight varies enormously. In licensed markets, operators submit to audits and their random number generators are tested, but the testing regime is built around card distribution and payout fairness. It is not obviously built to catch a UI state machine that disables a button two seconds early. That's not a failure of the auditors; it's a category they may not be looking at.
The offshore segment is worse. There's no audit, no regulator, and no realistic path to a fix other than public pressure. If the lockout is happening on an unlicensed site, the players' only recourse is to stop playing there — which some of them will, and some of them won't, because the site has soft games and the alternative is nothing.
Responsible gambling, briefly and without the pamphlet
A button that goes dead at a decision point is a small frustration. But it's worth naming the larger dynamic: friction at the moment of decision is exactly the kind of thing that pushes players toward faster, more automatic play. If you can't fold when you want to, you learn to fold earlier — or to not play the marginal spots at all. Neither is a disaster, but both make the game less interesting and, for a certain kind of player, more tilted.
If you find yourself clicking a dead button and getting angry about it, that's a signal worth heeding. The hand isn't the problem. Take the five minutes. The tables will still be there, and the operator's support queue will still be ignoring your ticket.
What the operator won't say, and what players can do
I sent two emails to the operator's press address over eight days. The first went unanswered. The second got an automated acknowledgment and nothing else. A support chat transcript shared by one player shows an agent saying the issue had been "escalated to the technical team" and offering a free tournament ticket as compensation. The player declined the ticket and asked for a written explanation of the button state. He's still waiting.
That's the pattern in this corner of the industry: the bug is real enough that support acknowledges it, and vague enough that nobody will commit to a cause. Operators have little incentive to publish a postmortem on a UI defect that affects a small number of hands and doesn't move revenue. The rational move is to fix it quietly in a client update and never mention it again.
Which is probably what will happen. The more useful question is what players should do in the meantime, and the answer is unglamorous.
Record your sessions. Screen recording is cheap and the evidence is decisive. If you can show the button gray before the river and the hand history showing the fold, you have something an operator's support team can't wave away.
Test the timing yourself. Next time you're in a hand and considering a fold, watch the button rather than the cards. If it grays before the river, note the hand number. A dozen data points from a dozen players is a better dataset than any single player's spreadsheet.
Ask the operator directly, in writing, what the deadline is. Not "why is the button gray" — that gets you a canned response. Ask: "At what point in the hand does my action stop being accepted, and is that point before or after the river is dealt?" If the answer is "before," then the client is working as intended and the gray button is a design choice players can evaluate. If the answer is "after," then the client has a bug and the operator should say so.
Know your market. If you're in a licensed state, your regulator takes complaints and, in some cases, publishes them. If you're on an offshore site, you have no regulator, and the only lever is your own deposits. That's not a satisfying answer, but it's the accurate one.
The open question is whether the two-second lockout is a one-off or a sign of something more common: clients that quietly narrow the window in which players can act, in ways that are invisible until someone records their screen and counts the frames. Poker has spent two decades arguing about bot detection and collusion and rake. The input layer — the actual moment your click becomes an action — has gotten almost no scrutiny. It probably should.