The Breaking News Dress Rehearsal
Script and run a fake crisis end-to-end to stress test your product and your people at once
- Difficulty
- Advanced
- Time to result
- ~weeks to results
- Steps
- 5
- Confidence
- 95%
CNN's product team scripts a fictional breaking news event and runs the entire real workflow — from the news-gathering email to the moment someone hits publish — against the live platform, with engineers and support staff observing. It compresses weeks of usability, performance and process feedback into a three-minute simulated event. The rehearsal doubles as a load test, a usability test, and an org-wide dry run of the incident chain.
Origin
Developed by Upasna Gautam and CNN Digital's core platform team as one of four editorial touchpoints; borrowed conceptually from theatrical and emergency-services dress rehearsals rather than software QA practice.
Core principles
- 01If a tool cannot serve the workflow at crisis speed, it is useless regardless of how it performs at normal speed
- 02Script the scenario so it is repeatable and comparable across runs
- 03Engineers must watch the rehearsal live, not read a report about it
- 04Every crisis is different, so vary the script each time to widen the coverage
- 05A three-minute simulation can generate more signal than a month of tickets
How to run it
- 1
Write the script
Define the fictional incident, every role and team involved, and the sequence of events. At CNN this starts with the news-gathering team sending an email to writers and producers, then fans out to video, article, and the photo desk.
Pro tip Include the peripheral teams people forget — the photo desk, the support team — because their steps are usually where the real friction hides.
- 2
Use real tools and real people
Run the rehearsal in the actual production-grade communication tools and the actual platform, with real editorial stakeholders performing their real roles. A PM co-facilitates alongside an editorial lead.
Pro tip Co-facilitate with a respected user-side lead so participants treat it as their drill, not a product-team exercise.
Watch out A simulation run only by the product team measures the product team, not the workflow.
- 3
Time-box it from trigger to publish
Run the whole thing at real speed — from the minute the alert email is sent to the minute someone hits publish on the page. The compression is the point; it reveals what breaks under time pressure.
- 4
Staff observers, not just participants
Have engineers and the support team on hand purely to observe what happens while it happens. They see failure modes in situ instead of receiving a filtered bug report afterwards.
Pro tip Debrief immediately while the sequence is fresh — ask what worked as designed and what did not.
- 5
Vary the script and repeat
Because no two real crises are alike, change the scenario each cycle. Use each run to learn how far the system can be pushed and where the next stress test should aim.
Watch out One rehearsal proves one path works; it does not prove the platform is resilient.
In the wild
CNN built layers of infrastructure fallback for election night, and the still-in-development new content management platform was designated one of those fallback layers. During the 2020 election, an upstream service failed and traffic fell through to the new platform — the one the team had been rehearsing against for months.
→ The unfinished platform held and 'saved the day', serving as live validation that the system was stable, strong and secure enough to carry CNN through an election.
Common mistakes
Testing features in isolation instead of the crisis workflow
Features can pass QA individually and still fail when chained together under time pressure across six teams and three tools. Only an end-to-end scripted run exposes the seams.
Running the rehearsal without engineers watching
Second-hand bug reports lose the context of what the user was trying to do and how fast. Engineers who watch the drill build the mental model that makes later technical feasibility calls sharper.
Is it for you?
Best for
Product teams whose software is used under time pressure in a high-stakes event — newsrooms, incident response, trading, live commerce, emergency services
Not ideal for
Low-stakes async products where nothing catastrophic happens if a workflow takes an extra hour
From the transcript
“we create a script and do a simulation of a breaking news scenario to stress test our platform because all breaking news scenarios are definitely…”
“we say okay here's the news here's how it's gonna break and then we we run it”
“while that dress rehearsal is happening we have our engineers and our editorial support team on hand as well so they're observing what's happening”
“each one is different but it's a crazy amount of stuff and information you can gather in such a short span of time”
From the episode
An inside look at how CNN builds product
Upasna Gautam