Raid Timing Calculator Helix

How Twitch raids work in 2026

A raid sends your concurrent audience to another live channel as you end your stream. Twitch's default is to surface a raid notification with a 90-second accept window — the host can accept, decline, or let the timer expire. Hosts can opt into auto-accept in chat settings; many active channels do for trusted raids and leave the prompt in place for unknowns. The retention outcome depends on three independent factors that the math cannot replace each other: timing (target is live and not in their last fifteen minutes), category alignment (similar enough that raiders stay rather than dump to Browse), and chat culture (target welcomes raiders rather than treating them as noise to be cleaned up). This calculator focuses on timing and category-match. The other two are a community judgement no schema can encode for you.

The decisive moment is the first thirty seconds after the raid lands. Twitch weights retention roughly four times more heavily than initial reach in its recommendation algorithm, and the retention window for a raided viewer is the first 30-60 seconds. That's long enough to read the title, judge the host, and decide whether to stay. A well-timed raid into a host who's mid-segment, audibly engaged, and playing a category your audience already follows is the single most reliable organic-growth move smaller streamers have. Use the 60-second pre-raid window to type your raid message, then run /raid in chat once the host's category and viewer count line up.

Raid etiquette: the unwritten rules everyone breaks anyway

Never raid in a target's last fifteen minutes. The host ends and your audience dumps to Browse, where retention is roughly an order of magnitude worse than a healthy mid-stream raid. Pre-announce the target so your regulars can prep a raid message. Pick a target whose audience is within a 2× ratio of yours (overwhelming a 20-viewer stream with a 200-viewer raid is awkward; raiding a 2000-viewer stream with 100 viewers disappears in the crowd). Raiding friends back over a week builds a real hosting loop. The calculator's history panel surfaces under-raided regulars so you don't accidentally let a relationship lapse.

What "good timing" means: the 30-min arrival window

The base unit of the score is a thirty-minute arrival window. A raided viewer doesn't decide whether to stay in the first three seconds. The audio loads, the title parses, the host turns toward the camera, the chat scrolls past. Thirty minutes is the empirical window in which a raid's contribution to a target's session retention separates clearly from the host's organic baseline. Less than thirty and you're measuring noise; more than thirty and the raid signal blurs into whatever else happens in the host's stream that hour.

The calculator scores each candidate raid time by the fraction of that thirty-minute window that overlaps with the target's typical broadcast schedule. A perfect overlap (the entire window falls inside the target's typical hours) is the schedule dimension's 100%. A half-overlap is 50%. Landing entirely outside the typical schedule is 0%. The other dimensions (audience-fit, category match, live-now) multiply onto that base, never replacing it.

Why last-15-min raids fail (the dying-stream penalty)

A fifty-percent score penalty applies when the raid lands in the target's last fifteen minutes, because the only thing more demoralising than a no-retention raid is the politely-resigned "thanks for the raid, I was just heading out" wrap-up. Once the host clicks End, your audience routes to Twitch's Browse page, a retention killer when the alternatives are unrelated streams in different languages and categories. The fifteen-minute boundary is empirical, not legalistic: an audibly wrapping-up host produces measurable retention drops on viewers who arrive in the last quarter-hour, and that drop sets in even if the host technically has the technical bandwidth to host you back.

The penalty is steep on purpose. A naive overlap-only calculator would rank a raid landing in the target's final five minutes nearly as high as one landing in their middle hour. Both have full thirty-minute "schedule" overlap. The penalty corrects that asymmetry by penalising the part of the overlap window that's structurally bad for retention, not just statistically rare.

How the calculator scores a window

Five candidate raid offsets (your end time and ±15/30/45 minutes from it) are scored against every valid target, then averaged into a per-window aggregate. Each per-target score combines four signals:

1. Schedule overlap (the base, 0-100%): fraction of the 30-min window covered by the target's typical broadcast hours, multiplied by the last-15-min penalty when applicable.
2. Audience-size fit (multiplier, 0-1): 100% when the target's typical or current viewer count sits within 0.5×-2× of your CCV, 50% within 0.25×-4×, 0% outside that.
3. Live-now bonus (additive, +20 percentage points): applied when the target is currently streaming. The Helix /streams call captures this in real time; refreshing the page picks up status changes.
4. Category match bonus (additive, +10 percentage points): applied when the target's current game (or last broadcast game) matches the category you typed in your inputs. Game string is normalised case-insensitively.

The aggregate per-window score caps at 110 (overlap × audience + 30 of bonuses) but displays at most 100. That cap matters because rank order, not absolute number, is what the tool emits. A window with a clean overlap, a category match, and a live target sits at the top whether the absolute number rounds to 100 or 110.

Auto-fill from Helix VODs (and what it costs)

The single biggest UX wart the previous version of this calculator had was manual schedule entry. Five rows × three fields × five targets is a lot of typing for something most users abandoned at the second target. The current version takes a comma-separated list of handles and resolves each one server-side through three Helix endpoints: /users for the user_id and avatar, /videos for the last ten archived broadcasts, and /streams for the live snapshot. Schedule is derived from the published_at modal hour (UTC) plus the median ISO-8601 duration of the sample.

The trade-off: VODs disabled, sample size below three, or a recent schedule change all degrade the accuracy of the auto-fill. We surface the VOD sample size on every target row. Under three VODs is flagged as "small sample, verify" and the manual override fields stay one tap away. Helix data is cached for five minutes server-side; refreshing immediately doesn't pull new data, but waiting through one cache window and then re-running is the cheapest way to pick up a target who just went live.

Live-now status: the real-time signal

A target who's currently live changes the calculation entirely. The +20 percentage point bonus on the score makes sense because the live signal collapses two layers of guesswork: their schedule isn't a prediction any more, it's a fact, and you can see their current viewer count for the audience-fit check directly. Targets currently streaming the same category as you compound both the live and category-match bonuses for a +30 swing relative to a sensibly-scheduled offline candidate.

Use the Live Status Tracker for ongoing multi-channel monitoring outside this calculator. It polls every fifteen seconds with the same Helix /streams endpoint and works as an OBS browser source for at-a-glance tracking of your raid candidates while you stream.

Reading the 5 candidates: a worked example

Suppose your stream ends at 22:30 local. The calculator emits five candidates at 22:15, 22:30, 22:45, 23:00, and 23:15. With three targets (one regular co-streamer who starts at 19:00 and ends at 23:00, one whose streams run 21:00-01:00, and one whose schedule is shaky with a small VOD sample, overridden manually to 22:00-02:00), the windows typically rank with the +30 (23:00) candidate in second or third place because it lands in the last hour of target one (last-15-min penalty for that one target depending on exactly when their typical end falls), but inside the comfortable middle of targets two and three.

The top candidate is rarely 0/+45. It's usually +15 or +30 because most regular streamers' typical end times cluster around the half hour, and pushing your end fifteen minutes past theirs gives you the last-thirty-minutes-of-their-stream slot without triggering the penalty. Stream-end ±0 wins when your typical co-streamer has the same end time as you (the math is symmetric and the relationship is usually mutual). −15 wins only when a single high-priority target is wrapping up exactly at +30.

When the top score is still a bad raid

The score doesn't see three things, and each can make the algorithmic top pick the wrong human pick. The first is chat culture: some streamers actively dislike raids (they're trying to wrap up; their mod team isn't on shift; they explicitly run a "no raids" panel). The score doesn't know that. Pre-check by reading the target's panels or pinned message before the raid lands.

The second is your audience's mood: a thoughtful music-stream raiding into a screaming Just-Chatting roast doesn't retain even at 100% schedule overlap. Category match catches the headline but not the tonal subgenre — Hot Tub Streams and Conversation are both Just Chatting, but they don't share an audience.

The third is the target's relationship with you: someone you raided three times in the last fortnight and never raided back is a recipient who's politely tired of you. The history panel surfaces under-raided friends and over-raided strangers. Read it before the calculation, not after the disappointment.

The history panel and the 30-raid memory

The tool tracks your last thirty raids in localStorage: target handle plus timestamp plus an optional accepted/declined flag you can mark after the fact. The "Recent raids" panel above the inputs lets you re-add any past target to the current calculation in one tap, and the same data powers the "you've raided X four times in fourteen days; consider Y who you haven't touched in two months" warning we surface for over-concentrated raid graphs.

This data never leaves your browser. The localStorage key is namespaced under streamrise:raid-history:v1 so future schema changes won't blow it away. Wiping browser data wipes the history; Streamrise has no record of which channels you raid or how often, by design.

Cross-tools to use before and after a raid

Before raiding, run the Channel Audit on your top target to confirm their discovery surface is set (a target with no category set is flagged as such in their Helix /channels response, a sign their stream may be in setup mode, not actually live). The Affiliate Safety Checker grades your own ramp patterns so you don't accidentally trigger a manual reviewer flag by raiding into a fast-growth period.

After raiding, polish your raid-message-style title with the Stream Title Grader (the title your target sees in their raid alert is the first thing that decides whether their viewers stay), and align tags between rooms with the Tag Optimizer so that the raided audience reads your channel as topically continuous with the host's.