Post-rundown: reviewing execution logs
Use the Logs tab to see real IN and OUT times, screen delay, API request detail and attribution after the show.
After a show ends, the logs tell you what actually happened, not what was planned.
How to access logs
Open the rundown and switch to the Logs tab, next to Rundown at the top of the editor. Logs are available during the show as well as after it.
What the logs show
Each entry includes:
- Timestamp: when the action happened.
- Action type: element executed or stopped, graphic IN / OUT / field patch, sequence start and complete, errors.
- Element: which element, in which story and segment.
- On air record: the real IN and OUT times, and how long it actually held the screen. An entry marked missing OUT never got taken down.
- Air confirmed: whether a screen reported the content actually reaching the picture, and the screen delay between the command and the frame.
- API details: the full request and response: URL, method, request body, response status, response body.
- Attribution: who executed it, who was operating, and who built the rundown.
Using logs for debugging
- Look for error entries to find failed executions.
- Check the response status. A 400 or 500 points at the integration, not at the rundown.
- Review the request body to confirm the field values that were actually sent.
- Compare the planned time against the real IN to spot elements that arrived late, usually a clip that was not downloaded before air.
- An unconfirmed air with no screen delay means no screen reported the frame.
Exporting
Use Export logs to take the run away for review.
Exported timestamps are in the operator's timezone, not UTC. If you are cross-checking against another system's logs, convert before you compare. An hour offset here is easy to misread as a five-hour gap.
Log retention
Execution logs are kept for a number of days set by your plan. You can see the exact limit for your company under Company Settings → Plan and Billing. Older logs are cleaned up automatically.