Console Errors: what to verify before client handoff

Nothing sinks a handoff call like a client sharing their screen, clicking the primary CTA, and watching the button no-op while the console lights up red. Uptime can still be green. The PDF can still say "QA complete." The exception does not care.

SlaySlop defines Console errors simply: it "Captures runtime exceptions from a real browser session." Before you send the portal link, that is the UX bar I use for the runtime row. Not a vibe check. A concrete throw on a concrete URL.

Outcome you want at handoff

Launch URLs you promised should complete their primary flows without runtime exceptions in a clean browser session. Homepage, pricing, contact, checkout or lead form—whatever the SOW called done—come first. Secondary blog archives can wait unless they are the product.

You also want a short written record: URL, action taken, exception message or "none observed," plus whether Failed requests showed a dead script that explains a dead widget. That note survives the call better than "runtime looked fine."

Boundaries to state on the call

Say the quiet parts before someone asks. SlaySlop is read-only and public. Permission is required for sites you do not own or manage. It is not a pentest. It is not full application performance monitoring. A clean Console errors result does not mean Failed requests is clean, and it does not mean accessibility, SEO, or Legal checks passed.

Keep the sibling definition handy for the meeting: Failed requests "Finds failed public requests observed while pages render." Clients experience both as "the page is broken." You should still file them as different findings so the fix lands in the right layer.

The Website scanner product is explicit that rendered pages surface client-side errors static requests miss entirely. If your handoff packet only shows curl screenshots, you are not measuring what Console errors measures.

Happy path checklist before you send the portal

Work production hosts you claimed were done. Staging with a different bundle proves the wrong claim.

# Permissioned reachability spot-check before the meeting
for u in \
  "https://www.example.com/" \
  "https://www.example.com/pricing" \
  "https://www.example.com/contact"
do
  printf '%s -> ' "$u"
  curl -sI -o /dev/null -w '%{http_code}
' "$u"
done

Then for each URL:

1. Open in a clean profile (extensions off if your runbook says so).
2. Perform the primary action: open nav, toggle pricing, submit contact, add to cart—whatever you demo.
3. Note any runtime exception and the first useful stack frames.
4. Note failed script or XHR requests that explain a dead widget.
5. Copy the SlaySlop page link into the handoff doc if a finding already exists. Product casing matters in client PDFs too.
6. If you use fix prompts, keep them as engineer follow-ups, not as the handoff narrative. Clients need the URL and the symptom first.

SlaySlop attaches findings to routes. Put those URLs in the notes. "UX runtime looked fine" is not a note. "Console errors clean on / and /pricing after CTA click; Failed requests clear on those routes" is a note.

Pitfalls that embarrass you on the call

QA on an authenticated sticky session that never hits the logged-out throw. Staging builds with source maps that production minifies into a different failure. Third-party chat widgets disabled on staging and enabled on production day. Feature flags that flip at launch and load a new bundle that throws on first paint.

Another classic: declaring "only warnings" without reading. If SlaySlop filed Console errors, it is in the runtime-exception bucket the product describes—not a vague aesthetics complaint. Argue severity after you reproduce, not instead of reproducing.

Laptop-specific noise also bites. An agency engineer with ten extensions can see errors the client never sees, or miss errors an ad blocker was hiding. Prefer a clean profile for the final pass, same as you should for consent UI checks.

Sample handoff blurb you can paste

"We ran a clean-browser pass on /, /pricing, and /contact. Console errors (runtime exceptions in a real browser session) were clear on those routes after the primary click paths. Failed requests were reviewed on the same URLs. This is public-surface hygiene, not an APM export and not a pentest."

That paragraph sets expectations without promising magic. If a finding remains open, replace the middle sentence with the URL and the exception summary instead of deleting the whole blurb.

Related next step

Put Console errors and Failed requests on the same pre-call checklist. Share a scoped portal view if the client only needs UX runtime findings. Soft link: Console errors, Failed requests, and the checks catalog.