A run of show(also called a rundown, show flow, or ROS) is the timed, sequenced list of everything that happens in a live event: each segment, its planned start time and duration, who's responsible for it, and the cues or notes the crew needs when it's happening. It exists for two jobs, not one. Before the event, it's the planning document the team builds the show around. Once the event starts, it's the live script a show caller actually runs the event from, calling standby and go off it in real time while the schedule holds, slips, or gets cut on the fly. Most guides to a run of show only cover the first job. The second is where the document earns its keep.
Run of show vs agenda vs schedule vs rundown vs cue sheet
These five terms get used loosely, and mostly overlap, but they aren't identical. Here's how they actually differ:
| Term | What it is | How it differs from a run of show |
|---|---|---|
| Agenda | A list of topics or segments an audience or attendee sees. | Written to be read, not executed. No durations, owners, or cues, just what's happening and roughly when. |
| Schedule | A general timeline of when things start and end. | Covers timing but usually stops there, no dept ownership, no cue detail, no built-in expectation that it gets called live off. |
| Rundown | Same document as a run of show, different name. | No real difference. “Rundown” is more common in broadcast/news, “run of show” in corporate and live events. |
| Show flow | Same document again, a third common name. | Interchangeable with run of show and rundown, no meaningful distinction. |
| Cue sheet | A department-specific list of technical cues and their triggers. | Narrower and single-department (lighting, video, audio). A run of show is the full-event timeline every department works from; it should reference cues, not replace a department's own cue sheet. |
What actually goes in one
Row by row, a working run of show converges on the same handful of fields: a start time (ideally computed from durations, not hand-typed), a duration, the item or segment name, the department or person who owns it, and notes or cues the crew needs while it's live. The full column breakdown and a populated example table are in the run of show template guide, this page is about what the document is, not how to build one row by row.
Who uses one
- Show caller. Runs the live event off the run of show, calling standby and go to every department against it in real time.
- AV / technical director. Reads it for exact cue timing, what triggers on video, audio, and lighting, and how much lead time each cue needs.
- Stage manager. Uses it to track talent movement, changeovers, and whether the show is holding to plan or needs to be told to compress.
- Producer. Builds it before the event as the plan, then leans on it during the event to decide what gets cut, held, or pushed if something runs long.
When it gets built, and how it gets shared
On timing, Swapcard's FAQ says a run of show “should be created a few weeks before the event, once the structure, sessions, and key participants are confirmed,” and that it “should remain a living document, updated as the event evolves, right up to the day it happens.” Real-world timing varies more than that: working producers sometimes build one two days out, which is fine as long as it's the document the show actually gets called from.
Sharing it is where run of shows quietly fail, because half the crew ends up reading an older version. Swapcard's advice is to host it in a shared workspace so the most up-to-date version is centralized, to “limit access to ensure only designated owners make changes,” and to request department sign-off, then on show day pair the document with “a shared communication channel for real-time updates” such as walkie-talkies or a group chat. Webex adds the trigger for sending it: “Once you've confirmed speakers, talking points, and discussion topics, share the run sheet as soon as you can,” including with the production team “so that they can confirm transitions, production cues.” This is the job Runsheet's share links do: control, crew, and stage views off one rundown, so every screen is showing the current version and nobody is re-sending a file.
A short example
A half-day conference run of show might open with doors at 9:00, a 5-minute welcome at 9:30, a 25-minute keynote at 9:35 with a hard out because the room is booked again at noon, a changeover, a panel, a buffer block built in around 10:50 to absorb whatever ran long earlier, then a demo and closing remarks. Every row has a start time, a duration, an owner (host, AV, stage), and a note (mic count, lighting level, hard out). That's the planning half. The execution half is what happens when the keynote runs 10 minutes long and everything after it is now wrong, covered next.
The fields stay the same across event types, the segments change. A gala or fundraiser adds the auction and appeal blocks (Handbid lays a charity auction out as setup, registration, bidding, program, live auction and appeal, checkout, clean up). A wedding adds ceremony cues and the send-off. A livestream adds stream-start, graphics and lower-third cues, and a hard end. Worked variants per event type live in the run of show template guide.
The live side: standby, go, hold, reflow
A run of show isn't just filled out once and printed. During the show, it's read against the clock and called from, out loud, over comms. A short vocabulary covers most of it:
- Standby.The call that a cue is coming, give the department a moment to confirm they're ready before it's triggered.
- Go (or cue). The trigger to actually execute the cue that was just put on standby.
- Hold.A call to pause or delay a cue that was about to go, usually because something upstream isn't ready yet.
- Reflow. What should happen to every downstream start time the moment one segment runs long or short: they recompute automatically instead of someone retyping the rest of the column by hand, mid-show.
The calling conventions themselves, how far ahead to call standby, what to do when the show is running behind, are covered in How to Call a Show. If you're also comparing tools to build and run one in, the run of show software guide covers what to look for. Runsheet is built around exactly this two-part definition: build the run of show, then run the show live from the same document, with reflow and synced screens handled automatically.
FAQ
- What is a run of show?
- A run of show is the minute-by-minute schedule a live event is built and executed from: every segment, its planned start time and duration, who's responsible, and what cues or notes matter when it's happening. It's used two ways: as a planning document before the event, and as the live script a show caller runs the actual event from, calling standby and go off it in real time.
- What's the difference between a run of show and a rundown?
- None, in most productions. "Rundown" and "run of show" are used interchangeably for the same document. Broadcast and news teams lean toward "rundown," corporate and live-event teams lean toward "run of show," but they describe the same thing: a timed, sequenced list of what happens and when.
- What's the difference between a run of show and an agenda?
- An agenda tells attendees what's happening and roughly when. A run of show tells the crew what's happening, exactly when, how long it should take, who owns it, and what cue triggers the next thing. An agenda is written to be read. A run of show is written to be executed.
- Who writes the run of show?
- Usually whoever owns the event on the production side: a producer, stage manager, or the show caller who'll be calling it live. On larger shows it's assembled from pieces, AV timing from the technical director, content and speaker timing from the producer, then merged into one document so there's a single source of truth the whole crew works from.
- Is a run of show the same as a cue sheet?
- Not quite. A cue sheet is narrower: a list of individual technical cues (lighting, video, audio) and their triggers, usually owned by one department. A run of show is the full timeline every department works from, and it should reference the cues, not replace the cue sheet a department needs for its own execution.
- Can I share the run of show with speakers, vendors, or external partners?
- Yes, and the useful move is a filtered view per audience rather than the full crew document. A speaker needs their own slot, their tech check, and where to be beforehand. A vendor needs load-in, dock, and strike times. The crew needs every row and every cue. Sending the whole document to everyone buries the two or three lines each person actually has to act on, and exposes internal notes that aren't theirs to read. In Runsheet that's what role-based share links do: control, crew, and stage views off the same rundown, so each audience gets a link scoped to what it needs.
- What are the most common run of show mistakes?
- vFairs lists five in its run of show guide: no contingency plan or buffer time, incomplete instructions on each row, ignoring technical requirements, scheduling too rigidly, and skipping rehearsal. They all fail the same way live: the show slips, and a document with no buffer, no per-row detail, and no rehearsal behind it can't tell anyone what to do next. Buffer blocks, one clear instruction per row, and a rehearsal pass are what make a run of show callable rather than just readable.
Build the rundown. Run the show. Every screen in sync.
Runsheet is the hosted place to build a run of show and then run it live, no setup, share links for control, crew, and stage screens. Free for 1 rundown, 3 connected screens.
Start free