Live Event Technical Runbook: Pre-show Checklist, Incident Response Workflow, and Postmortem Template

Overview

Technical problems are easier to manage when the team has already decided what to check, who can make changes, and when to switch to a backup plan. This runbook is designed for livestreams, webinars, virtual meetings, hybrid events, and productions that connect tools such as OBS, Streamlabs, Zoom, Microsoft Teams, Discord, Twitch, or YouTube Live.

Keep one copy in a shared workspace and one accessible offline. Replace the bracketed fields with event-specific details:

• Event: [name, date, time zone, expected duration]
• Technical lead: [name and contact method]
• Host or presenter lead: [name]
• Moderator or audience support: [name]
• Primary platform and event link: [URL]
• Backup destination or meeting room: [URL]
• Escalation contacts: [platform support, internet provider, venue, internal IT]

For equipment dependencies, review the streaming setup compatibility guide. For account access, stream keys, and permissions, use the stream key and account permissions security guide before rehearsal.

Checklist by scenario

One to seven days before the event

• Confirm the platform, event URL, visibility setting, scheduled start time, and assigned account owner.
• Verify that the host, producer, moderator, and backup operator can sign in and reach the required controls.
• Confirm that the stream key or connection method is stored securely and is not pasted into public documents or chat.
• Document the intended video resolution, frame rate, encoder, audio sample rate, and target bitrate. Use settings the production computer and connection can sustain rather than selecting the highest available option.
• Check every input: camera, capture card, microphone, audio interface, presentation source, media playback, and on-screen graphics.
• Prepare a clean test scene and a holding scene. Remove private notifications, unrelated browser tabs, and confidential desktop content.
• Confirm recording storage, available disk space, power adapters, cable spares, and a way to contact the team if the primary chat fails.
• Review the live event backup and failover plan and decide in advance when to move to the backup host, recording, connection, or platform.

During the technical rehearsal

• Run the complete sequence, including opening music, slides, camera changes, screen sharing, video playback, captions or transcripts, audience questions, and closing scenes.
• Have someone watch the output from a separate device and network if possible. Check lip sync, voice clarity, loudness consistency, aspect ratio, overlays, and unintended feedback.
• Start a private or unlisted test where the platform supports it. Confirm that the encoder connects, the preview appears, and the platform receives both video and audio.
• Record a short sample and play it back. A local preview can look acceptable while the recorded or distributed output has missing audio, delay, dropped frames, or an incorrect source.
• Write down the last known good configuration. Save the production profile or scene collection only after testing it.

During the live event

Use a simple incident response workflow: observe, classify, isolate, communicate, recover, and record. The technical lead should avoid making several unrelated changes at once.

1. Observe: Note the exact symptom, start time, affected audience or speaker, and whether the problem is visible in the local preview, platform preview, or public output.
2. Classify: Label the incident as audio, video, network, platform, account, presentation, or audience-access trouble.
3. Isolate: Test one variable at a time. For example, switch to a known-good microphone, hide a browser source, stop a heavy application, or move to the holding scene.
4. Communicate: Give the host a short status message and a next action. Avoid technical speculation on the public broadcast.
5. Recover: Apply the smallest reversible fix. If recovery exceeds the agreed threshold, use the backup plan rather than extending an uncertain diagnosis.
6. Record: Capture the time, symptom, action, result, and person responsible. This makes the postmortem useful.

Quick checks for common incidents

• Mic not working on stream: confirm the correct input is selected, check mute states in both the operating system and production software, inspect the level meter, and test a known-good input.
• Stream audio issues or echo: mute duplicate sources, check whether a meeting participant is monitoring the broadcast, use headphones, and verify that only the intended audio path is active. The Zoom echo and microphone checklist covers related meeting symptoms.
• Dropped frames or unstable video: check whether the issue is rendering, encoding, or network-related; reduce scene complexity or output load; and move to a lower tested profile if necessary. See the OBS encoder and dropped-frames guide.
• Screen share has no audio: verify that application audio sharing is enabled, the correct window is selected, and the source is not muted in the mixer. Test media playback before returning live.
• Platform connection fails: confirm account access and event details, check the platform's official status information, test the network, and use the documented backup destination if the service appears unavailable.

What to double-check

Before going live, the technical lead should read the following list aloud and receive a clear confirmation for each item:

• The public event URL works in a private browser window.
• The correct account, channel, event, and privacy setting are selected.
• The stream key or authentication method is current, private, and available to the approved operator.
• The audience can hear speech, but not private monitoring, backstage conversation, or duplicate audio.
• The camera is framed correctly, lighting is stable, and slides are legible at the chosen output size.
• Presenter names, lower thirds, captions, links, and graphics contain no outdated details.
• Recording is enabled if required, and the destination has enough space.
• Someone is watching chat, questions, access reports, and moderation alerts separately from the person operating the encoder.
• The team knows the exact phrase or visual cue that means “switch to backup,” “pause,” or “end the event.”

For a broader rehearsal sequence, compare this runbook with the live webinar checklist. For complex workflows that connect a meeting platform to a broadcast destination, the streaming and video meeting integration playbook can help identify handoff points.

Common mistakes

• Testing only the local preview: Always verify the distributed output or a recording. The audience may receive a different mix or quality level.
• Changing several settings at once: Multiple changes hide the cause and make it difficult to restore the last known good state. Save a baseline first.
• Leaving troubleshooting on air: Use a holding scene, slate, or prepared message while the operator investigates.
• Making the host the technical support desk: Assign a producer or operator to diagnose issues so the presenter can continue the program.
• Ignoring the audio path: Viewers usually notice missing, echoing, or distorted speech before minor video imperfections. Test every microphone and playback source.
• Relying on one person, device, or connection: A backup operator, recording, cable, power source, or network path can prevent a small failure from ending the event.
• Skipping the postmortem: Without a short review, the team repeats the same fixes and assumptions at the next broadcast.

When to revisit

Review this runbook before every live event, even if the format is familiar. Perform a fuller update before seasonal planning cycles, after changing platforms or production software, when adding a camera or capture device, and after changing the venue, network, host, or moderation workflow.

After each event, complete this postmortem while details are still fresh:

1. Event and impact: What happened, when, and who or what was affected?
2. Timeline: When was the issue detected, communicated, mitigated, and resolved?
3. Root or contributing cause: What evidence supports the explanation? Separate confirmed causes from assumptions.
4. Response: Which action worked, which did not, and whether the backup plan was used.
5. Follow-up: Assign an owner and due date for each change to equipment, permissions, training, documentation, or testing.

Update the runbook whenever a workflow or tool changes, and refresh platform-specific steps before a major event rather than relying on memory. Use the live stream quality troubleshooting decision tree for recurring audio, video, and network symptoms, and review the live stream analytics review template to connect technical quality with audience behavior. A runbook is effective only when it reflects the setup that will actually be used next.