How to Check Whether a Release Broke Something — A Post-Deploy Checklist

Short answer: after every release, check four things using real user data: new JavaScript errors, step conversion in your key flows, frustration signals on changed pages, and performance by device. Check at fifteen minutes, one hour, and one day. Then watch five real sessions through the flow you changed.

Table of Contents

1. Why Passing Tests Is Not Enough
2. Before You Deploy
3. The First Fifteen Minutes
4. The First Hour
5. The First Day
6. When to Roll Back
7. Key Takeaways

Why Passing Tests Is Not Enough

Automated tests run in a clean environment with known data. Real users bring what tests do not:

• Browsers and versions you did not test
• Old tabs still running the previous version's code
• Extensions, ad blockers, and translation tools that alter the page
• Accounts with unusual data
• Slow networks and low-powered phones
• Third-party scripts that changed on their own schedule

The gap between "tests pass" and "users succeed" is where most production incidents live.

Before You Deploy

• [ ] Note the current error rate and top error groups
• [ ] Note step conversion for the flows you are touching
• [ ] Note Core Web Vitals for the affected pages, by device
• [ ] Write down the deploy time
• [ ] Avoid deploying at the same moment as a campaign or price change

Without a baseline, you cannot tell a regression from normal variation.

The First Fifteen Minutes

Errors

• [ ] Open JavaScript errors and look for groups that first appeared after the deploy time
• [ ] Sort by affected sessions, not total count
• [ ] Open a session for any new group and see what the user was doing

Live traffic

• [ ] Watch real visitors move through the changed flow. With live session view on Pro and above, you can filter the session list to Live and watch as it happens
• [ ] Confirm at least one real user completes the flow

Old tabs

• [ ] Look for chunk or script loading failures from visitors who had the site open before the deploy. In single-page apps, navigation after a deploy can request files that no longer exist

The First Hour

Key flows

• [ ] Compare step conversion in your funnels with the same hour on a comparable day
• [ ] Split by device. A regression often affects one layout only

Frustration

• [ ] Check rage clicks and dead clicks on the changed pages
• [ ] Watch Highlights in a few sessions for repeated attempts

Performance

• [ ] Compare real-user LCP and INP on the affected pages (performance)
• [ ] Look at mobile separately

Network

• [ ] In a few recordings, check the network timeline for failing or slow requests

The First Day

• [ ] Conversion on the affected goals against the same weekday last week
• [ ] Error groups: did any grow slowly rather than spike?
• [ ] Performance at the 75th percentile, by device
• [ ] Support tickets mentioning the changed area
• [ ] Browser breakdown of any new errors
• [ ] Sessions from the less common browsers and screen sizes

On Business and Enterprise plans, Pulse runs detectors daily for rage-click spikes, funnel regressions, error surges, and dead-end pages, and reports them in a brief with links to the evidence.

When to Roll Back

Decide the threshold before the release, not during an incident.

"Roll back first, understand later" is nearly always right for anything touching revenue. The recordings and errors remain available for the investigation.

What Makes This Fast

The checks above take minutes when errors, funnels, performance, and recordings share the same sessions. An error opens the session where it happened, a funnel drop opens the sessions that stopped there, and each recording carries its console and network timeline. When those live in separate tools, verifying a release becomes a long manual task, and it gets skipped.

Key Takeaways

• Take a baseline before deploying.
• Check errors, flows, frustration, and performance at three intervals.
• Split everything by device.
• Watch five real sessions through whatever you changed.

Conclusion

A release is not finished when the deploy succeeds. It is finished when real users have completed the flow you changed.

Start free with DeepSync.