Cloud OBS Show Caller Runbook for IRL Events

The useful split

A show caller is the person who keeps the live plan moving. For an IRL event, that job should not be dumped on the streamer holding the camera. The field host is already handling movement, guests, audio, chat energy, personal safety, and whatever the venue throws at them. The show caller watches the run of show, calls scene changes, and gives the producer short instructions.

Cloud OBS makes that split practical. StreamableRun can receive the field feed, hold Cloud Hosted OBS scenes, manage fallback states, route destinations, and give a remote producer a place to operate. The show caller does not need to touch every button. They need to say what should happen next in clear language.

The goal is a calmer stream. If the source drops, the caller says fallback. If the sponsor segment starts, the caller says sponsor slate. If the host enters a private area, the caller says privacy. If YouTube is healthy but Kick needs attention, the caller keeps the public show moving while the destination checker handles that platform.

Why IRL events need a caller

Casual IRL can be loose. Events are different. A convention walk has booth timing. A charity stream has donation beats. A streamer house has guest rotations. A tournament has match timing. A sponsor segment has talking points and disclosure. Without one person calling the order, everyone waits for everyone else.

The caller is not a bossy extra role. It is the person who reduces live ambiguity. The producer can stay focused on Cloud OBS and destinations. Mods can watch chat and privacy reports. The streamer can keep being watchable. The caller keeps the run of show from living inside five people's heads.

OBS's remote control guide notes that built-in WebSocket support can control scenes and sources with external tools. That is powerful, but it does not replace human timing. The caller decides intent. The producer executes inside the controlled StreamableRun workflow.

Write a one-page run of show

The run of show should fit on one page. Long docs feel responsible until nobody reads them during a live issue. Use time, segment, active source, scene, destination note, and recovery action. If the event is loose, use order instead of exact time.

Each segment should answer five questions. Who is on camera? Which source is expected? Which Cloud OBS scene is live? Are paid overlays or chat widgets normal, compact, or paused? What fallback should the producer use if the source drops?

Do not write paragraphs in the live runbook. Put details in a prep doc if needed. The live version should be scanned in seconds by the caller, producer, and mods.

• Segment name: arrival, booth walk, guest, game, sponsor, recap, ending.
• Expected source: main phone, backup phone, local OBS, guest, clips.
• Expected scene: main, two-up, safe slate, sponsor, clips, ending.
• Overlay mode: normal, compact, sponsor-safe, paused.
• Recovery: fallback, backup source, clips, destination-only fix, or end cleanly.

Put the caller above the tools

The caller should not be buried in dashboards. They need the public program feed, team voice or chat, run of show, and a small source status view. The producer needs the actual controls. If the caller and producer are the same person, keep the run simpler because one brain is doing two jobs.

StreamableRun is helpful because the producer's work can stay around Cloud Hosted OBS, ingests, fallback, and destinations. The caller can call human timing: go to guest, hold clips, pause alerts, privacy slate, return to main, end after this beat. That separation prevents tool fiddling from taking over the show.

The caller also protects the streamer from over-instruction. Field hosts cannot process a paragraph while walking through a crowd. Give them short instructions: pause here, turn left, hold on sign, repeat sponsor line, move outside, audio check, stop filming. Anything more detailed should go to the producer.

• Caller watches the show and run order.
• Producer touches Cloud OBS and StreamableRun controls.
• Destination checker watches public playback.
• Mods watch chat, reports, and privacy flags.
• Streamer gets only field instructions they can act on immediately.

Build scenes around caller calls

Scene names should match caller language. If the caller says privacy slate, there should be a scene named Privacy Slate. If the caller says clips, there should be a Clips scene. If the caller says sponsor, the producer should not have to choose between six sponsor variations with unclear names.

OBS Browser Source can render custom overlays, chat widgets, alerts, and web content inside OBS. That makes scenes powerful, but it also means a scene can carry too many moving parts. Event scenes should be cleaner than casual scenes because the caller needs predictable outcomes.

Use a small scene set: Main Field, Backup Field, Guest Two-Up, Sponsor Slate, Privacy Slate, Reconnecting, Clips, Destination Check, and Ending. Add more only when the event truly needs it.

• Scene names should be spoken exactly the same way in the runbook.
• Only one person should rename scenes after rehearsal starts.
• Every safety scene should be above experimental overlays in priority.
• Clips and fallback scenes should have safe audio levels.
• Destination check scenes should never expose stream keys or private dashboards.

Have a source-loss call

Source loss is the most common scary moment in IRL. The caller should not ask a committee what to do. The default call should already be written. For most events, that call is fallback now, streamer reconnects, producer keeps destinations live, destination checker verifies public playback.

SRT and SRTLA help the contribution path, but they do not remove the need for a public fallback. OBS's SRT guide explains latency and connection modes; that is transport detail. The live production decision is what viewers see when the transport fails anyway.

In StreamableRun, build the fallback as part of Cloud OBS. It can be a reconnecting slate, safe clips, sponsor-safe hold, map screen, or event intermission. The caller should know which fallback belongs to which segment.

• Main field drops during casual segment: Reconnecting or Clips.
• Main field drops during sponsor segment: Sponsor Hold.
• Main field becomes unsafe: Privacy Slate.
• Main field drops near planned desk segment: Local OBS if ready.
• All sources unstable: Clips, status update, then decide whether to end.

Handle destination issues without panic

A destination problem should not automatically become a whole-show problem. If Twitch is healthy and Kick reconnects, the caller should keep the program moving while the destination checker handles Kick. If YouTube needs a bitrate adjustment for a future stream, write it down after the segment instead of changing everything live.

YouTube's encoder guidance lists different bitrate ranges by resolution and codec. Twitch's broadcasting guidance gives practical output recommendations for Twitch. Those settings matter, but an event runbook should avoid live experiments unless the public show is already protected by fallback or backup.

Route destinations from StreamableRun when possible. That keeps platform keys and output decisions away from field devices. It also gives the team a cleaner recovery path: field source recovers at the ingest layer, scenes recover in Cloud OBS, destinations recover at the output layer.

• One person watches public playback per destination.
• Destination issue does not mean source issue.
• Do not restart a healthy platform because another platform is unhappy.
• Write platform-specific recovery actions before the event.
• End cleanly only when the caller and producer agree the show cannot recover.

Rehearse like the caller will actually call

The rehearsal should use the same words as the live show. If the caller says privacy slate in rehearsal but emergency cut live, the producer may hesitate. Keep the vocabulary stable. Run the top five calls until they feel boring.

Practice the awkward parts: guest arrives early, source drops, streamer walks into private area, sponsor segment starts late, destination checker reports a platform issue, and chat says audio is bad. The caller's job is not to solve every technical detail. It is to decide the next show state and let the right person act.

After rehearsal, remove unused scenes and stale notes. Too many options make the caller slower. A clean StreamableRun runbook should make the first response obvious even if the event is messy.

• Call Privacy Slate and confirm producer switches within seconds.
• Call Clips and verify public playback stays live.
• Call Sponsor Scene and confirm paid overlays are paused.
• Call Backup Source and confirm audio state.
• Call End Clean and confirm destinations stop intentionally.

Other resources

These StreamableRun guides help turn the show caller role into a complete Cloud OBS event workflow.