Console errors that only appear after hydration

Uptime can be green while the console screams after JavaScript takes over. That pattern embarrasses agencies on launch calls: the client opens DevTools on a phone, sees red, and suddenly your "we tested it" slide looks thin. Static fetches never saw the exception. Hydration did.

SlaySlop's Console errors check "captures runtime exceptions from a real browser session." It lives under UX beside Failed requests, Linked pages, and Technology detection. The Website scanner product stresses the same idea: a real browser, not just a curl, rendered pages surface client-side errors that static requests miss entirely.

Outcome

You want runtime exceptions on key public routes captured with page context before handoff. The ticket should name the route and the error signal, not "JS feels flaky." Failed requests ("finds failed public requests observed while pages render") often sit next door when a hydration path calls a broken endpoint.

Boundaries

Read-only browser session. Permission required. Not a pentest. Console noise is not an exploit license. Do not paste session tokens from the console into chat. Do not ask the scanner to run arbitrary scripts on third-party sites.

A clean console on the homepage does not prove checkout is clean. Linked pages discovery helps map what else is public; still spot-check critical templates.

Happy path: catch what curl cannot

I still curl first to see if the document itself fails. Then I stop trusting curl for UX runtime.

# Authorized host, proves document fetch, not hydration health
curl -sI "https://www.client.example/app" | sed -n '1,15p'

In a real browser (or the SlaySlop scan that already used one), watch for exceptions during and after hydration: mismatched markup warnings that escalate, undefined reads on feature flags, third-party tags throwing when a consent path races. Technology detection ("identifies public framework and service signals used by the site") can hint which runtime you are looking at; it does not replace the console row.

When you fix, prefer eliminating the throw over swallowing it with an empty catch. Rescan the same URL. If Failed requests also fired, fix the network dependency in the same change set when they share a root cause.

Pitfalls

Saying "it's only a warning" when the client demo still shows a red badge. Ignoring third-party tag errors because "that is the vendor." Your page is still where the exception appeared. Another pitfall: fixing staging and forgetting production's different bundle hash.

Hydration mismatches that only appear on slow networks still count. Office Wi-Fi calm is not evidence. Interaction readiness reviews responsive interaction signals; a page that throws on first input may show up in more than one category. Keep the console finding specific so you do not boil the ocean.

Related next step

Before the portal goes to the client, open Console errors and Failed requests on the primary templates. Fix throws, rescan, then talk about polish. A read-only scan on slayslop.com is the straightforward way to capture the runtime session evidence.

Handoff language that does not overclaim

On the call, say you captured runtime exceptions in a real browser session on the routes that matter. Do not say you "QA'd every possible device." Do not say console-clean equals bug-free. Point at the Console errors row and any Failed requests beside it.

If a third-party tag is the source, either fix consent timing, remove the tag, or accept an open finding with an owner named on the client side. Silent acceptance without an owner is how the same red console returns at renewal.

Pairing with fix prompts

When Console errors includes a stack that points at your code, the SlaySlop fix prompt path is fair game: open finding, copy prompt, paste into Cursor, review, rescan. When the stack is purely a third-party tag, the prompt may still help you gate the tag, but the owner might be marketing ops. Put that owner in the ticket before the agent invents a rewrite of your app shell.