Broken transactions are more costly than slow ones. If a login fails without warning, a checkout gets stuck at payment, or a form submits without confirmation, these problems can go unnoticed for hours while users leave your site. You'll usually know something went wrong with a transaction because your monitoring tool alerts you. The real challenge is figuring out the issue—what broke, at which step, and why—quickly enough to fix it before it gets worse. Metrics like response time graphs, waterfall charts, and error logs are useful, but they don’t show what the browser actually displayed at the time the problem occurred. That’s where session recordings from Site24x7's synthetic monitoring RCA comes in.
What is a session recording?
Session recordings are videos of simulated user interactions on a website or app capturing mouse movements, clicks, scrolls, and navigation paths as they happen. They let teams replay exactly what a user experienced, making it easier to spot friction points, debug issues, and understand behavior that analytics numbers alone can't explain. When your critical web transactions are monitored using Site24x7's synthetic transaction monitors, these recordings will be available as part of the RCA reports.
Every time your monitored transaction runs, the browser captures the actions: how the page loads, how individual resources load, scripts, the checkout flow, and the moments when something stalls or breaks. If a check fails or performance drops, the session recording becomes your main visual evidence.
For example, a waterfall chart might show that a third-party payment script took six seconds to load at Step 4 of a checkout flow. The session recording shows what the user actually saw during those six seconds: a visible payment form with an unresponsive submit button, with no error message and no indication that anything was wrong.
How can you obtain the broken web transaction session recording in Site24x7?
You can retrieve an in-depth RCA report for your down monitors, which includes a session recording, 150 seconds after the monitor reported the outage.
To access it:
- Go to your Web Transaction (Browser) monitor details page.
- Navigate to the Outages tab.
- Click into an outage entry to open the RCA report.
- The video appears alongside the waterfall chart, console errors, screenshot comparison, and network diagnostics. You can also run an on-demand check by selecting Poll Now. This lets you instantly see the status of a monitored resource. The report includes the session recording for that check, which is helpful if you want to investigate a possible issue right away rather than waiting for a scheduled check to fail.
Types of transaction issues the session recording reveals
Session recordings are especially helpful for problems that metrics don’t explain well, such as broken transactions due to something on the page failing, stalling, or behaving unexpectedly.
For example, in a broken multi-step flow, a transaction might involve several steps, such as loading a page, clicking a button, submitting a form, and reaching a confirmation screen. If something breaks at any step or in the case of any transaction step failure, the whole transaction fails. The session recording shows exactly where the process stopped and what the browser displayed at that moment, whether it’s an error message, a blank page, a redirect to the wrong URL, or no change at all.
Silent form failures are another example. Sometimes a form appears to submit, but the transaction doesn’t actually complete. This failure is hard to catch with metrics alone because the HTTP response might return a 200 status and the page load time might seem normal, even though the right page didn’t load. The session recording makes this clear: you see the form submit, but the page either stays the same or reloads back to the form instead of moving to the confirmation page.
Broken elements and missing components are also easier to spot. The monitor's Down status is triggered when something important, like a payment button, product image, or confirmation message, is missing or not visible. The recording shows this clearly: the page loads, but something that should be there isn't. This can happen due to a DOM rendering failure, a JavaScript error blocking component initialization, an A/B test variant serving the wrong layout, or a geo-restriction preventing certain assets from loading at that monitoring location.
Finally, for slow or unresponsive interactions, page load time is measured for each step, including load time, mouse hover actions, and button clicks. If clicking a button causes a three-second delay before the next page loads, the session recording captures that wait just as the user would see it. Instead of showing only a millisecond value, it reveals the actual pause in the flow.
Use case: Catching a broken checkout after a deployment
An e-commerce team monitors its five-step checkout flow—product page, cart, shipping details, payment, and order confirmation—using a Web Transaction (Browser) monitor in Site24x7, running every ten minutes from three United States locations: Dallas, Seattle, and Atlanta.
On a Tuesday afternoon, the monitor reports Down status at the payment stage (Step 4). Transaction time spikes from a baseline of 6.2 seconds to a reported timeout. A failed web transaction alert is fired to Slack within minutes.
The on-call engineer opens the RCA report. The RCA report includes checks from the primary location and re-checks from a secondary location, resource-level waterfall chart, console errors, session recording, screenshot comparison, HTML comparison, ping analysis, DNS analysis, and TCP traceroute.
The session recording shows the cart and shipping steps completing normally. At Step 4, the payment iframe loads—and then stalls. The page sits with the payment form visible but the submit button unresponsive for the full timeout duration.
The waterfall chart for the step shows a request to a third-party payment processor's script returning a 503 error. The console errors confirm a JavaScript exception from that same domain. The HTML comparison highlights added lines in green and removed lines in red and the diff shows that a script tag pointing to the payment processor's CDN was modified in the most recent deployment, pointing to a versioned path that no longer exists.
The fix is straightforward once the cause is clear. The script path is corrected, Poll Now confirms the checkout flow completes end to end, and the incident is resolved in under 30 minutes. Without the session recording, the engineer's first instinct might have been to look at server-side logs—a longer path to the same answer.When your app is also monitored by Site24x7's application performance monitoring tool using the same account, trace data is available for each transaction step directly within the RCA report. This enables you to connect a front-end failure visible in the session recording to the specific back-end service call that caused it, without ever switching tools.
Using session recording alongside the other RCA features
Session recording works best when used in combination with the rest of the RCA report, not in isolation. Here's how to incorporate it into your RCA process.
Start with the transaction summary. Transaction details include screenshots of each step, step time, page load time, step names, resource-level waterfall charts for each page, and console errors raised in each step. Identify the failing step first. Go directly to that timestamp in the video rather than watching the full session.
Cross-reference with the waterfall chart. The waterfall chart helps analyze the performance of each component on a page Site24x7, showing DNS time, connection time, first byte time, and a full breakdown of resources by request count, size, and domain. If the session recording shows a page stalling, the waterfall chart tells you which resource caused the stall.
Use screenshot and HTML comparison for regressions. Screenshot comparison lets you compare a screenshot from when the monitor transaction step was up with one from when it was down. HTML comparison shows added lines in green and removed lines in red. Site24x7 When combined with the session recording, this pairing answers two questions at once: what changed in the code, and what did that change look like to users.
Check console errors. A JavaScript exception that doesn't generate an HTTP error code will still appear in the console error log, and you'll see its effect in the session recording as an interaction that doesn't complete, a component that doesn't render, or a step that doesn't advance.
Check the Apdex score for user satisfaction context. The Web Transaction (Browser) dashboard surfaces an Apdex score alongside your performance metrics. A score below 0.5 indicates frustrated users—if your session recording shows a transaction stalling or breaking, the Apdex score tells you how broadly that experience is affecting your user base relative to your defined satisfaction threshold.
A practical web transaction troubleshooting workflow
When a transaction alert fires, don't just click through reports at random. Instead, work through these troubleshooting steps:
- Check the transaction summary first. Which step failed or slowed? What’s the transaction time vs. baseline? Is the issue isolated to one location or global?
- Open the waterfall chart for that step. Find the longest bars. Is the delay in DNS, connection, first byte, or download? Is it your origin or a third party?
- Watch the session recording and go to the timestamp of the step with the problem. What did the browser actually show? Does what you see match what the numbers indicate? Check for console errors. Errors that happen in each step are recorded in the transaction details. A JavaScript exception that doesn’t cause an HTTP error will still show up here, and you’ll also see it in the video as something that didn’t work.
- Compare screenshots with the last health check. Use the screenshot and HTML comparison to identify what changed. If nothing changed on your end, check whether a third-party resource changed.
- Use Poll Now to check your fix. After you make a change, run Poll Now to confirm the problem is solved instead of waiting for the next scheduled check.
- Use Zia-based thresholds to you track the abnormal spikes using anomaly detection. These support dynamic thresholds, which will be updated accordingly.
How a session recording changes the troubleshooting conversation
Session recordings are helpful for more than just quick diagnosis. If a developer says, “I can’t reproduce the issue,” or a product manager asks, “How bad was the failure for users?” the session recording gives an answer that everyone can understand without needing technical explanation. A 2.8-second First Contentful Paint can be seen as benign or urgent depending on the context. But, a video showing a blank screen for almost three seconds before anything appears is a clear issue to everyone. This makes it much easier to decide what to fix first.
Used alongside Site24x7's waterfall charts, console error logs, screenshot comparisons, and HTML diffs, session recordings shorten the path from alert to fix and make every member of your team understand what went wrong and why it matters—whether they're technical or not. Start monitoring your web transactions today to catch issues before your users do.
Frequently asked questions
What is a web transaction in the context of monitoring?
A web transaction is a series of user actions on a website or app, like logging in, searching for a product, adding an item to a cart, and checking out. These steps are monitored as a single workflow. Unlike a simple uptime check that just pings a URL, web transaction monitoring runs through the whole transaction process in a real browser and checks that each step works. If any step fails, the transaction status is marked Down, and you receive an alert.
What is a monitoring session recording and how is it different from a session replay?
A monitoring session recording shows what a synthetic browser displayed during a scheduled transaction check. It does not record real user visits, whereas session replay gives details of real user interactions on a site or a web app.
What types of transaction issues can session recordings detect that metrics alone can't?
Metrics tell you that something went wrong and roughly when it happened. Session recordings show you what the user sees. Issues that metrics describe poorly but videos reveal clearly include: silent form submission failures where a page reloads instead of advancing, broken elements that never appear on screen despite a 200 OK response, layout shifts that move interactive elements just as the browser tries to click them, redirect loops that land on the wrong page, and interactions that appear to complete but leave the transaction stuck without advancing to the next step.
How does Site24x7 generate a session recording for a failed transaction?
When a Web Transaction (Browser) monitor finds a failure, Site24x7 creates an RCA report about 150 seconds after the Down status is reported. This report includes a session recording by the synthetic browser during the failed check, a resource waterfall chart, console errors, a screenshot comparison, an HTML diff, a ping analysis, a DNS analysis, and a TCP traceroute. You can find the recording in the Outages tab on the monitor's details page. No manual setup is needed to utilize this feature.
Can I get a session recording without waiting for a transaction to fail?
Yes. Site24x7's Poll Now feature lets you run an on-demand check at any time from the monitor's details page. The Poll Now report includes a session recording for that check, step-by-step screenshots, the waterfall chart, and console errors. This is especially helpful after you deploy a fix, since you can visually confirm that the transaction works without waiting for the next scheduled check.
What is the difference between transaction time and page load time in web transaction monitoring?
These are two different metrics that people often mix up. Page load time is the time it takes to fully load the HTML and all resources, such as JavaScript, images, and fonts, for a single step in the transaction. Transaction time is the total time to complete all steps, including both response time and the wait time between steps. The waiting time, called think time, gives AJAX calls a chance to finish before the next step. If the response time for a step exceeds the think time, the think time is not counted in the transaction time.
What causes a web transaction to show a Trouble status versus a Down status in Site24x7?
Site24x7 distinguishes between these two statuses based on what the monitor detected. A Trouble status is triggered specifically by a content check failure—the page loaded, but the expected text, element, or value was not found in the response. A Down status is triggered when the monitor cannot load any resources, when a required element is not present or visible on the page, or when a content check fails in a way that prevents the transaction from advancing. Understanding which status fired tells you immediately whether the issue is a complete failure or a functional one.
How should I use the Apdex score alongside session recordings when troubleshooting?
The Apdex score in the Web Transaction (Browser) dashboard measures user satisfaction on a scale from 0 to 1. A score above 0.9 indicates satisfied users, 0.5 to 0.9 indicates tolerating users, and below 0.5 indicates frustrated users. When a session recording shows a transaction stalling or breaking, the Apdex score adds population-level context. It tells you whether this experience is affecting your broader user base or is isolated to specific locations or times. Use the Apdex trend over time alongside the session recording to prioritize whether a fix is urgent or can be scheduled.
Can I connect session recordings data to back-end traces in Site24x7?
Yes, if your app is also monitored by Site24x7's application performance monitoring tool, APM Insight, under the same account. When APM Insight is active, trace data for each transaction step appears directly within the RCA report alongside the session recording, waterfall chart, and console errors. This means you can go from a front-end failure visible in the session recording—such as a payment iframe that stalls—to the exact back-end service call that caused it, without switching tools or correlating data manually. Check the APM Insight documentation.
How long does Site24x7 retain session recordings for Web Transaction (Browser) monitors?
Site24x7 stores session recordings in the RCA report for each outage. To see how long your session recordings are kept, check the Site24x7 support docs or contact our support team, since retention depends on your subscription. It’s smart to download or export RCA reports for important outages soon after they’re resolved. This gives you a record for post-mortems, stakeholder reviews, or compliance, regardless of the platform’s retention limits.
What is the minimum check frequency for a Web Transaction (Browser) monitor?
You can set Site24x7 Web Transaction (Browser) monitors to run every 10 minutes, which is the shortest interval allowed. Each check needs time to finish all browser steps. If you need faster feedback, use the Poll Now feature to run a check immediately. This is useful during deployments, when investigating issues, or before a major release.
Does session recording work differently for single-page applications (SPAs)?
SPAs are different to monitor because moving between views does not reload the whole page like traditional apps. In Site24x7's Web Transaction (Browser) monitor, each step in your script corresponds to a specific action, such as a click, form submission, or URL change, rather than a full page load. You can still monitor SPA flows step by step if your script closely follows the user journey. The session recording records the browser’s actions, so you can see what happens after a route change or component update, even if the page does not reload.