Failed Requests: what to verify before client handoff

I still reach for curl first. Headers look fine. Then I open the browser and watch three chunks 404 while the hero paints. Handoff needs the second step. SlaySlop's Failed requests check "Finds failed public requests observed while pages render."

That sentence is what I put at the top of the portal note. Not "site works." Not "Lighthouse was okay once on my laptop."

Outcome before you hand the keys over

In-scope URLs render without a pile of failed public requests you would be ashamed to show on a shared screen. Each leftover finding has an owner and a route. Console errors is reviewed beside it, not mashed into the same vague "JS issues" sticky note.

Linked pages and technology detection can stay in the UX category without stealing this ticket. Discovery and fingerprinting answer different questions than "did this request fail while the page rendered?"

Boundaries

Permissioned, read-only scan. Not a pentest. Not a promise about logged-in app shells you excluded. Uptime green ≠ failed-request clean. Performance metrics are siblings under Performance, not a replacement for naming the broken URL.

Website scanner copy is blunt: real browser, not just a curl; evidence on every finding; critical issues stay on top. Acceptable Use still applies—only scan hosts you own, manage, or have permission to test.

Happy path checklist

1. Freeze the URL list you promised (home, pricing, signup, contact, key landing pages).
2. Review Failed requests findings on those routes.
3. Reproduce in a clean browser with the network panel open.
4. Fix origin/CDN/third-party references. Prefer repairing the request over catching the error in empty try/catch theater.
5. Glance at Console errors for follow-on exceptions ("Captures runtime exceptions from a real browser session").
6. Rescan. Paste cleared routes into the handoff note.

cat <<'URLS'
https://www.client.example/
https://www.client.example/pricing
https://www.client.example/signup
URLS

curl -sI "https://www.client.example/pricing" | sed -n '1,12p'

A document 200 only proves the HTML arrived. The Failed requests check cares about the public requests that fire afterward.

handoff_note:
  check: Failed requests
  definition: failed public requests observed while pages render
  routes_cleared: / /pricing /signup
  open: none
  console_errors_sibling: clear|open

When I am rushed, I still force myself to click the primary CTA on each SOW URL once. Failures that only appear after interaction are easy to miss if you only stare at the initial waterfall.

Pitfalls

Shipping with "only third-party failures" when that third party owns checkout. Verifying on a laptop full of ad blockers. Fixing one locale and ignoring the localized CDN path. Declaring victory from a single Lighthouse run that never loaded the broken interaction. Closing Monitoring-related tickets and assuming render-time network health came along for the ride.

Another common miss: fixing the asset on staging and forgetting production still references the old hashed filename. Rescan the host the client will actually open.

Related next step

After Failed requests is quiet on the SOW routes, read Console errors and—if the page feels slow but requests succeed—Performance audit on the Performance and accessibility product. Soft links: Failed requests, Console errors, Website scanner. A permissioned SlaySlop rescan is the boring proof I want in the portal before the call.

Minimum evidence pack I attach

1. SOW URL list used for the scan.
2. Failed requests findings before fix (page + request URL + status).
3. Fix PR or CMS change reference.
4. Rescan timestamp and cleared state.
5. Console errors sibling status on the same URLs.

That pack survives a staff change better than a Slack thread that says "should be fine now."