IRL Stream Incident Review Template for Producers and Mods

The point of the review

An IRL incident review should make the next stream easier to operate. It is not a blame meeting, a diary, or a dramatic post about how hard streaming is. It is a short record of what viewers saw, what the team did, which recovery actions worked, and what needs to change before the next route.

IRL streams fail in normal ways: phone signal drops, SRT latency is wrong, RTMP source disappears, audio goes silent, a guest walks into a private shot, a destination buffers, or a producer switches to the wrong scene. If the team does not review those moments, the same scuff returns with a new costume.

StreamableRun gives serious streamers a better recovery layer because ingests, Cloud Hosted OBS, fallback scenes, clips, destinations, and remote production controls can all be part of the same runbook. The incident review turns that runbook into something sharper instead of letting every show reset to memory.

Keep it short and factual

The best review is usually one page per incident, written the same day. People remember the order better before everyone sleeps, travels, or starts editing clips. Use timestamps, states, observed symptoms, action taken, result, and next change. Do not write paragraphs of emotion unless they explain an operational fact.

Use neutral language. Main phone source dropped at 01:14:22 is useful. Phone was terrible again is not. Producer cut to clips after twenty-two seconds is useful. Everyone panicked is only useful if it leads to a specific fix, like adding a caller command or simplifying scene names.

OBS logs, platform dashboards, public playback, and mod reports can all tell different parts of the story. None of them should be treated as the only truth. The review should separate what was observed from what the team thinks caused it.

• Observed: what viewers, mods, producer, or streamer saw.
• Action: what the team did during the incident.
• Result: whether the action helped, hurt, or did nothing.
• Cause: only what is supported by logs, testing, or clear evidence.
• Change: one specific fix before the next stream.

Start with viewer impact

Review what viewers actually experienced before reviewing the internal dashboard. Did the public stream end? Did it freeze? Did audio disappear? Did viewers see a fallback scene? Did chat understand the status? Did one destination fail while another stayed healthy?

This order keeps the team honest. A source may have looked ugly in the producer preview while the public output stayed fine. Or the dashboard may have looked healthy while YouTube viewers reported buffering. The incident severity should follow the public show, not the loudest internal alert.

StreamableRun's strongest value during an incident is preserving the public show state. If the phone source drops but Cloud OBS keeps a clean clips scene live and destinations stay connected, that is a very different incident from a platform session ending.

• Did the platform session stay live?
• Did viewers see the intended fallback?
• Was audio understandable during recovery?
• Did mods give a correct public status message?
• Did the streamer have to stop the segment to fix settings?

Separate source, scene, and destination failures

Many teams lose time because they call every incident a drop. A source failure means the field feed has trouble. A scene failure means Cloud OBS showed the wrong thing, wrong audio, or wrong overlay. A destination failure means Twitch, Kick, YouTube, or custom RTMP output had trouble. Those need different fixes.

OBS's SRT guide explains connection modes, latency, and SRT URLs. YouTube publishes encoder bitrate guidance for live streams. Twitch publishes broadcasting guidance for Twitch output. Those docs are useful only if the team knows which layer had the problem.

Do not lower every bitrate because one browser source covered the wrong frame. Do not rebuild scenes because a carrier dead zone killed the phone source. Do not blame the phone if only one destination buffered. The review should name the layer first, then the fix.

• Source layer: phone app, encoder, camera, network, battery, heat, microphone.
• Scene layer: Cloud OBS scene, browser source, audio routing, fallback, labels.
• Destination layer: Twitch, Kick, YouTube, custom RTMP, output bitrate, key, platform status.
• Team layer: late call, unclear role, missing status message, wrong escalation.
• Policy layer: privacy, sponsor, music, guest consent, platform rules.

Use a small severity scale

Severity helps the team decide how much to change. Not every warning needs a rebuild. If a producer saw a short source dip but viewers never noticed, log it and watch for repeats. If the public stream ended, that is a major incident. If a privacy cut happened late, treat it seriously even if the stream stayed live.

Use a four-level scale. Level 1 is internal warning only. Level 2 is visible scuff with clean recovery. Level 3 is viewer-impacting incident that needed fallback, backup, or destination work. Level 4 is stream-ending, privacy-sensitive, sponsor-sensitive, or repeated failure.

Do not inflate severity to make the review feel important. The goal is better operations. If everything is Level 4, the team will stop trusting the scale.

• Level 1: internal alert, no visible viewer impact.
• Level 2: visible issue, fast recovery, no lost session.
• Level 3: fallback or backup needed, noticeable viewer impact.
• Level 4: stream ended, privacy risk, sponsor risk, repeated failure, or unsafe situation.
• Privacy and safety can raise severity even when the technical stream stayed healthy.

Review the first response

The first response matters more than the final theory. Did the producer cut to fallback quickly? Did mods update chat? Did the streamer get a simple instruction? Did someone check public playback? Did everyone talk at once?

If the first response was slow, fix the runbook before changing gear. Maybe the fallback scene name was unclear. Maybe the producer did not know whether they were allowed to cut away. Maybe the mod did not have approved status copy. Maybe the streamer was asked to debug while walking.

StreamableRun can make the first response easier because the fallback and destination controls are part of the cloud workflow. But the team still needs permission and practice. A button nobody feels allowed to press might as well not exist.

• Who noticed first?
• Who made the call?
• Who touched the controls?
• What did viewers see during the first thirty seconds?
• What exact change makes the first response faster next time?

Turn causes into tests

Do not leave the review with vague causes. Bad signal is not a test. Indoor market route loses main phone at 4 Mbps is a test. Browser source audio too loud during fallback is a test. Kick output shows buffering at current bitrate while Twitch is healthy is a test.

Every cause should become a rehearsal or configuration change. Lower a preset. Rename a scene. Add a backup source. Move fallback audio down. Assign a destination checker. Add a privacy command. Remove a browser source from the sponsor scene. Then test it before the next public stream.

If the team cannot test the proposed fix, write it as an assumption. That keeps the review honest. Guessing is normal; pretending guesses are facts is how the same incident returns.

• Change one setting at a time when possible.
• Record the test result with date, route, source, bitrate, and destination.
• Keep failed tests because they prevent repeated experiments.
• Turn repeated incidents into checklist items.
• Remove fixes that make the workflow harder without improving recovery.

Template to copy into your runbook

Use this structure after every serious scuff. Keep it in the producer doc, not in public copy. The public article, VOD description, or sponsor recap can be much shorter. The internal review is for the team.

Incident title. Date and stream. Timestamp. Public viewer state. Platforms affected. Source, scene, destination, team, or policy layer. Severity. What happened. First response. Recovery action. Result. Evidence. Probable cause. What we will change. Test before next stream. Owner. Due date.

The owner and due date matter. Without them, the review becomes content. With them, it becomes production work. Assign one person to each fix and keep the list short enough that it will actually happen.

• Owner: one person, not everyone.
• Due date: before the next similar stream.
• Evidence: clip, log, public playback note, mod report, or dashboard screenshot.
• Change: one clear action, not a hope.
• Test: how the team will prove the change works.

What not to put in the review

Do not store private customer data, stream keys, private emails, payment details, guest personal information, exact home addresses, unreleased sponsor details, or sensitive safety notes in a broad team doc. Keep private details in the smallest place they need to live.

Do not write insults about guests, mods, or platforms. If a person made a mistake, name the operational fix: unclear role, missing checklist, no final-call owner, untested scene, wrong permission. The review should be safe for a future producer to read without inheriting drama.

Do not turn every review into a sales memo. StreamableRun should appear in the runbook where it helps: ingests, Cloud OBS, fallback, clips, destinations, remote production, and testing. The useful proof is the recovery path, not repeated product language.

Other resources

These guides help connect the incident review to concrete rehearsal, audio, failover, and stream health work.