Delay is a clock problem before it is a feature problem
A streamer adds a ninety-second delay to protect a competitive match from stream snipers. Reasonable. Then a viewer pays for a TTS message that says react to that play, and by the time the message reaches the public stream the play is nearly two minutes old. The streamer sees the message in real time on their own screen, reads it, and responds to something the viewers have not watched yet. The paid moment lands, but it feels off to everyone involved.
Delay does not break paid features. It splits your show into two clocks: the one the streamer and moderators live in, and the one viewers live in. Every paid moment crosses from one to the other. The job is to decide, feature by feature, which clock the viewer is promised.
What a bot can and cannot know about your delay
Twitch's API reference describes a delay field in Get Channel Information as the broadcaster's stream delay setting, in seconds. The same description says the value defaults to zero unless three conditions hold: the request uses a user access token, the broadcaster ID matches the token's user, and the broadcaster has partner status and has set a non-zero delay. In other words, a tool using an app token, or one running for a non-partner, will read zero even if the stream is delayed by other means.
Delay can also come from broadcast software or an encoder in the chain, and those do not show up in the Twitch field at all. Twitch's Partner Settings Guide covers the platform-side setting and its current limits, so check that article instead of trusting a number you remember.
The practical rule is that the number a tool reports is a hint at best. Treat the streamer's measured delay as the real value and store it as a manual setting that someone updates when it changes.
Measure it in two minutes
Add a browser source or text source to a scene that shows the current time with seconds. Go live, then watch the public stream on a second device that is not on your local network, ideally a phone on mobile data. Compare the clock on the phone with the clock on your own machine. The difference is your effective delay for that session.
Do this at the start of each stream. Normal platform latency moves around, and a delay setting applied by someone else on the team may have changed since last week. Write the number on the moderator sheet where everyone can see it. If it is 8 seconds, almost nothing in this post matters. If it is 90 seconds, nearly all of it does.
- Clock source in a scene, visible on the public output.
- Second device, different network, watching the real stream.
- Note the gap. Repeat if the delay setting changes.
- Put the measured number on the moderator sheet.
Tell viewers before they pay, not after
A viewer who pays and sees nothing for ninety seconds will assume the purchase failed. They type in chat, they ask for a refund, or they pay again. Most of that is avoidable with one line near the paid button or in the queue status.
Phrase it in terms of what they will see, not in jargon. For example: this stream runs on a delay, so your message may take about a minute and a half to reach the broadcast. If the delay changes, change the number. If you do not know it exactly, say about and round up.
Also keep the status honest. A queue that says playing now when it means playing on your screen is wrong for the viewer. If your queue exposes states, make sure the viewer-facing wording describes the broadcast the viewer is watching, not the room the streamer is sitting in.
Who watches which screen
Moderators have two views available. The dashboard view runs on the real-time clock. The public stream runs on the delayed one. Decide which one is the source of truth for which decision, and say so.
Approving and rejecting happens on the real-time clock. That is an advantage: moderators review items while the streamer has not yet played them, and the viewers have not seen anything. Verifying that a paid item actually appeared correctly is a delayed-clock job. If a moderator checks the public output right after pressing approve, they will see nothing for the length of the delay and may approve it a second time or report a failure that is not there.
Give moderators a rule of thumb: approve now, verify after the delay, and do not retry until the delay has passed. If your sheet shows the delay, the rule is easy to follow.
A worked timeline with a 75-second delay
Take a stream with a measured delay of 75 seconds and a paid TTS message that costs a few dollars. At 0 seconds the viewer pays and the item enters the queue. At 20 seconds a moderator approves it. At 35 seconds it reaches the front and plays on the streamer's screen, so the streamer laughs and answers it in real time. The viewer who paid does not see or hear any of that until about 110 seconds, which is 35 plus the 75-second delay.
That is one minute and fifty seconds of silence from the viewer's side. A queue status that flipped to played at 35 seconds is telling the viewer something that has not happened for them yet. The status line, the moderator note, and any thank-you in chat should all use the broadcast clock. A moderator who wants to confirm the item landed should look at the public stream at or after the 110-second mark.
The same math applies in reverse for a streamer who wants to stop something. If a moderator realizes at 40 seconds that a message should not have played, the viewers have not seen it yet, but nothing in a plain delay lets you pull it out of the buffer. The only real protection is the approval step that happened before the item played.
Chat runs ahead of the video
Viewers read chat in real time and watch video late. When a big moment happens, chat reacts before the broadcast shows the cause. For paid features, that creates a spoiler: someone pays for a moment, the streamer reacts in real time, chat comments on it, and viewers see messages about an alert that has not reached their screen yet.
You cannot remove that effect, but you can reduce its damage. Keep paid moments short so the gap does not stack. Avoid features whose whole point is surprise, such as a mystery effect or a hidden reveal, when the delay is long. If you run them anyway, ask mods to avoid describing the outcome in chat until the broadcast catches up.
Check this with a test from a second account instead of relying on assumptions about how chat and video line up for your viewers. Send a message and see how far ahead it appears relative to the video.
Features that depend on right now
Some paid and interactive features quietly assume there is no delay. A vote that closes in thirty seconds works if viewers see the question immediately. With a ninety-second delay, the vote is over before the question reaches the screen. A paid prompt such as comment on what you just did refers to a moment the audience saw a minute ago. A countdown to a sponsor read shows the wrong number if it runs on one clock and the video on the other.
- Votes and polls: lengthen the window by the delay, or run them on a pre-announced schedule.
- Live-reaction prompts: rewrite the paid copy so it does not say right now or just now.
- Countdowns: run them inside the scene so they travel with the video, not on a separate site.
- Surprise effects: pause or limit them while the delay is long.
A rough policy by delay length
These thresholds are judgment calls, not platform rules, so adjust them for your show. They are meant to give moderators a starting point rather than a debate.
Under about 15 seconds, treat it like normal platform latency and change nothing. Between 15 and 60 seconds, add the viewer-facing delay line and the moderator rule about not retrying. Over 60 seconds, shorten the windows for votes, rewrite live-reaction prompts, and ask whether paid features that depend on immediacy are worth keeping open at all during the delayed segment.
Delay and ad breaks
If you run ad breaks during a delayed stream, remember that the break reaches viewers on the delayed clock. A moderator holding the paid queue on the real-time clock will release too early if they use the ad's start time as a guide for the public view. Add the delay to your release estimate and confirm on the public output, which is the same human check that works for any ad hold.
Quick answers
Can my bot read my stream delay from Twitch?
Sometimes. Twitch's Get Channel Information delay field is only populated for a partner using their own user token with a non-zero delay. Otherwise it reads zero, so keep a manually entered number.
Does a delay make paid TTS safer?
Not by itself. A delay buffers the broadcast but does not edit it. Safety still comes from approving items before they play. The delay only changes when viewers see the result.
Why does my moderator say a paid message did not play?
They are probably watching the public stream and checking too early. Verify after the measured delay has passed, and avoid retrying before then.
Should I keep paid polls open during a long delay?
Only if you lengthen the voting window by the delay. If viewers cannot see the question before the vote closes, the result will not mean much.