Browser Runtime Health: practical fix guide

A page can return 200, look fine in a quick screenshot, and still be quietly broken. A checkout button may depend on a script that never loaded. A pricing widget may throw an exception on startup. An old image path may keep returning 404 on every visit.

Browser Runtime Health looks at what happens after the HTML reaches a real browser, which is where these failures finally become visible.

What Scavo checks

During Scavo's rendered root-page probe, it records:

• uncaught JavaScript exceptions;
• messages logged through console.error;
• failed first-party scripts, stylesheets, API requests, images, and fonts; and
• first-party runtime resources that return an HTTP error status.

An uncaught exception or failed first-party script is a failure because it can stop a feature from starting at all. Other console or resource errors are warnings: they still need review, but a missing image is not treated like a crashed application.

• Scan key: browser_runtime_health
• Category: TECHNICAL

Why this matters

Runtime failures are excellent at slipping between teams. The server is up, monitoring sees a 200, and the page shell renders, so everyone assumes the journey works. The person trying to submit the form gets a button that does nothing.

Even smaller errors have a cost. Repeated failed requests waste bandwidth, make debugging noisy, and train developers to ignore the console. Keeping the baseline clean makes a new error much easier to spot.

If you are not technical

1. Send the first error and affected URL to whoever owns the website frontend or deployment.
2. Tell them which action matters on that page, such as opening the menu, submitting a form, or starting checkout.
3. Ask for the root cause, not just a screenshot showing that the page opens.
4. Confirm the failed asset or request has been fixed on the live site, including any CDN cache.
5. Re-run Scavo on the same URL.

Scavo found a browser runtime problem on the root page (browser_runtime_health). Please reproduce the first listed uncaught exception, console error, or first-party resource failure in a clean browser session, fix the source or deployment path, add a regression check for the affected journey, and re-run the live scan.

If you are technical

Start with the first uncaught exception or failed script. Later messages are often just knock-on effects.

A practical debugging order

1. Reproduce with browser developer tools open and preserve the console/network log.
2. Check whether the failure happens before or after consent, authentication, or a feature flag changes state.
3. For 404 or 5xx resources, compare the built asset manifest with the URLs emitted by the live HTML and JavaScript.
4. For an exception, use the production source map if one is safely available to your team and trace the first application-owned stack frame.
5. Test a clean session as well as a returning session; stale service workers and cached bundles can create version mismatches.
6. Clear or invalidate edge caches only where needed, then verify the exact production route.

Do not make console.error disappear just to turn the check green. Fix the underlying failure or downgrade intentional diagnostic output to an appropriate log level.

How to verify

• Load the live route in a clean browser context.
• Confirm there are no uncaught exceptions during initial render.
• Filter the network panel to failed requests and check first-party scripts, styles, fetch/XHR calls, images, and fonts.
• Exercise the important control on the page; the current Scavo check covers initial rendered load, not every interaction.
• Add a browser smoke test for the route and action that failed.
• Re-run Scavo and compare the evidence list.

What this scan cannot confirm

• The current check observes the root page's initial rendered state, not every internal route or logged-in journey.
• It does not click every button, submit forms, or complete checkout.
• A clean result does not replace application error monitoring or browser end-to-end tests.
• Third-party failures are excluded from the first-party resource count to avoid blaming a site for intentionally blocked tracker traffic.
• Errors that only occur for a particular account, region, device, or timing condition may need a targeted reproduction.

Sources

• MDN: Window error event
• Playwright: Page events
• Playwright: pageerror event