Rehearsal routines and failover checklists for live gallery crews
Daniel Prowse
6 min read
Part two of our look at Production Workflow Planning: how we build rehearsal routines and failover checklists so a live programme stays on air when a source drops or a cue is missed.
Why rehearsal is where reliability is made
In the first part of this subject we dealt with run sheets. A run sheet tells the crew what should happen. A rehearsal tells you what actually happens when twelve people try to do it together, with real cameras, real talkback and a presenter who has never seen the desk lit before.
We treat rehearsal as a test of the whole system rather than a courtesy to the talent. During the weeks since the clocks changed, several of our clients have moved their evening programmes earlier, which leaves less daylight margin for set-up and more reliance on a routine that is already written down.
A good rehearsal has a purpose stated at the start. Is it checking the running order, the cameras, the graphics hand-offs or the fault response? Mixing all four in one pass usually proves none of them properly, and the crew leaves unsure what was actually settled.
Shaping a rehearsal routine that people will keep using
We build routines in layers. The first layer is a technical line-up before anyone sits down: sources present, tallies correct, intercom channels labelled, audio levels set against a tone reference. It should take the same time every day, because a routine that varies in length is a routine that gets skipped.
The second layer is a walk-through of the programme with the real timings, stopping only for faults. The third is a short, deliberate run of the awkward moments: the live link that arrives late, the guest who sits in the wrong chair, the package that finishes early.
We write each layer as a single page that a floor manager can hold. If it needs a manual to follow, it will not be followed at ten to six with the doors about to open.
- Technical line-up first, always in the same order
- Walk-through at real timings, stopping only for faults
- One rehearsed pass of the three most awkward moments
- Each layer on one page, readable at arm's length
What a failover checklist actually contains
A failover checklist is not a list of everything that might break. It is a short list of the failures that would take you off air or leave you with unusable sound, each paired with the first action, who takes it, and how long you have before the audience notices.
We start from the signal path. For each critical point, such as the main vision mixer, the router, the master clock or the programme audio feed, we ask what the crew would see and hear if it failed, and what the quickest safe alternative is. That alternative might be a second mixer output, a pre-patched backup microphone or a held slide with clean audio.
The answers go in plain language at the top of each card. The explanation of why sits underneath, for the engineer who reads it later, not the director who needs it now.
- Name the failure as the crew would first notice it
- State the first action and the person who owns it
- Give the time available before viewers notice
- Keep the reasoning below the action, not above
Practising the fault, not just reading about it
A checklist nobody has used is a hope rather than a procedure. We ask clients to rehearse a chosen fault at least once a quarter, outside transmission, with the whole gallery taking part. Pull a camera feed, drop the talkback, freeze the playout and watch what the crew does.
The first time, people look at the card. By the third time they have stopped needing it, and the card becomes a record of agreed behaviour instead of an instruction. That shift is the real goal.
These drills also expose things the card cannot. A patch that is labelled differently on the rack and on the drawing, a headset that has no spare battery, a button nobody realised was latched. We note each finding, fix it and amend the card the same day.
Who decides, and when
Under pressure, ambiguity about authority costs more than the fault itself. Every routine we write names one person who calls a switch to backup and one who confirms it, and states plainly that the call can be made without asking permission from the editor or the station manager.
We also set the point at which the crew stops trying to repair and moves to a safe state. Engineers dislike giving up on a fault. A written threshold, such as thirty seconds without a restored source, removes the argument and keeps the programme moving.
After transmission, a short review of two or three minutes closes the loop. What triggered a card, what was missing, what was clear. Those notes feed the next revision, so the paperwork stays tied to how the studio really behaves.
- One named person calls the switch to backup
- One named person confirms it on talkback
- A written threshold for stopping repairs
- A two-minute review after any card was used
Keeping the documents honest over time
Paperwork drifts. Equipment is replaced, a presenter changes, a graphics system is updated, and the checklist quietly describes a studio that no longer exists. We date every card and attach it to the system drawing it refers to, so a change to one prompts a look at the other.
We recommend a light review once a season rather than a heavy one once a year. In mid autumn, with the longer evenings and the busiest schedules ahead, it is a sensible moment to walk each card against the room and remove anything that is no longer true.
Where we have handed over a studio, the routines go with it in a form the client's own team can edit. Our aim is that nobody needs to call us to change a line on a card.
Rehearsal routines and failover checklists are modest documents, but they are what lets a crew behave calmly when something goes wrong. Keep them short, test them aloud, name who decides and revise them as the studio changes. If you would like help drafting or testing yours, contact us through the contact page and we will talk through your current gallery set-up.
Daniel Prowse
Senior Broadcast EngineerDaniel designs signal flow and gallery systems, and writes the documentation every handover relies on.