Failed Requests and false confidence from a quick glance

I have opened DevTools, watched the document row go green, and moved on. Later a client recorded a blank hero image and a dead font. The glance found a successful HTML response. It did not answer whether public requests failed while the page rendered.

SlaySlop's Failed requests check "Finds failed public requests observed while pages render." Observed during render is the useful part. Presence of a 200 on the document is not automatically a clean network session.

Outcome I want from a Failed requests pass

Fewer cases where visual QA signs off and a real-browser session still records 404s, blocked hosts, or failed XHRs on the routes you demo. On launch URLs, I want a short list of failed public requests with page evidence—or a credible empty list.

What a quick glance gets wrong

A glance catches the document status. It misses assets loaded after hydration. It misses third-party hosts that fail only on cold cache. It conflates Console errors with network failures: Console errors "Captures runtime exceptions from a real browser session." Different signal. Different ticket.

I still start with a permissioned curl when I want the raw document shape:

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

Then I remember curl is not a render. It does not execute the client graph that triggers the rest of the requests.

How the signal is actually observed

Practical sequence aligned with published product language:

1. Open public pages in a real browser context as part of the scan.
2. Allow the page to render so client-initiated requests can fire.
3. Record public requests that fail during that render.
4. Attach findings to the page where they were observed.
5. Keep Console errors as a sibling UX check, not a substitute.

The Performance and accessibility product frames the wider idea: findings show where the site works technically but breaks for real users. A document that returns 200 while critical assets fail is exactly that shape.

Boundaries that keep the lab note honest

Read-only. Public pages. Permission required. Not a pentest. SlaySlop does not edit the site. Authenticated areas outside a public scan stay your own harness problem. Do not invent product claims about private dashboards the check never opened.

Sibling labels to keep clean:

• Console errors: runtime exceptions from a real browser session
• Availability status: whether the public site responds and records its state
• Interaction readiness: browser signals related to responsive interaction

Fixing a failed request does not clear an exception that already threw. Clearing an exception does not revive a dead CDN object.

False confidence patterns I keep in the notebook

"Network is quiet." Filters hid 4xx. Clear filters. Sort by status.

"It works on my machine." Service Worker or disk cache served yesterday's good asset. Hard reload on a clean profile.

"Third party, ignore." If the failure owns a visible control, it is still a public-surface problem.

"We monitored uptime." Uptime probes the reachability question. Failed requests watches render-time public requests. Both can be true at once: Up, and messy.

Lab note template
URL:
Failed resource:
Status / error:
First-party? (yes/no)
UX impact: (CTA / cosmetic / unknown)
Sibling Console errors? (yes/no)

Happy path verification without the glance trap

Open the cited URL in a clean browser profile. Reproduce the primary click path. Read the network failures with filters off. Confirm whether the failure is first-party or vendor. File with URL + resource. Rescan the same public URL after the fix.

When I am comparing before and after a deploy, I keep the failing resource URL in the lab note, not just "fonts looked bad." Resource identity is what makes a rescan meaningful. If the HTML changes hashes, confirm the new object exists before you celebrate.

# Permissioned: pin the URL you will rescan after the CDN fix
printf 'rescan=%s\n' "https://www.example.com/pricing"

When the glance is especially misleading

Single-page apps make this worse. The document arrives once. Then a router click triggers a new batch of public requests. A glance at the first waterfall never saw the second. Failed requests observed while pages render includes that later work when the scan session exercises discovered paths.

Service workers add another false calm. A worker can serve a cached good asset while a fresh install on a client laptop misses the object entirely. Clean-profile verification is not ceremonial. It is how you stop arguing from two different network realities.

I also watch for "failed" that is really "blocked by client policy" in my own QA browser. Extensions are not the public surface. Confirm on a stock profile before you file a vendor war.

Related next step

When I want the catalog definition beside the ticket, I keep Failed requests open and refuse to close on document status alone.