Common Failed Requests mistakes that still ship

What an attacker—or a client on a Loom—sees on the public surface is simple: the page asked the network for something and the network said no. Status codes, blocked hosts, dead CDN paths. The UI can still look "fine" in a screenshot.

SlaySlop's Failed requests check "Finds failed public requests observed while pages render." The mistakes below are how teams still ship under green uptime while that row lights up.

Outcome if you fix these early

Fewer launch-week tickets that say "images are broken" without a URL. A habit of reading the network tab on the same routes you demo. Console errors and Failed requests treated as siblings, not synonyms.

Boundaries

Public read-only scanning. Permission required. Not a pentest. Failed requests ≠ Console errors. Console errors "Captures runtime exceptions from a real browser session." A missing script may produce both a failed request and a later throw. SlaySlop will not fix your CDN for you. Do not scan hosts you do not own, manage, or have permission to test.

Happy path: the mistakes I still see

Mistake 1: Trusting the document status code

curl -sI "https://www.example.com/pricing" | head -n 1
# HTTP/2 200

That line says the HTML arrived. It does not say every stylesheet, font, XHR, or beacon succeeded while the page rendered. I still see teams stop at the document 200 and call the network clean.

Mistake 2: Staging CDN paths in production

Production HTML points at cdn-staging.example.com or a preview bucket that 404s for the world. Designers never noticed because their hosts file still resolves staging. The public surface does. Failed requests will.

Mistake 3: Treating third-party failures as "not our bug"

Chat widgets, CMP scripts, analytics, and ad tags fail constantly. If they own a visible control or block a primary path, the visitor does not care which vendor signed the Host header. Remove, upgrade, or isolate. Do not close the finding as external noise without checking UX impact.

Mistake 4: Ignoring soft failures and filtered network views

Some CDNs return odd statuses for missing objects. Others return clear 404 or 403. Teams grep only for exceptions in the console and miss the red network rows. Read Failed requests and Console errors together. Clear DevTools filters before you declare the waterfall clean.

Mistake 5: No route on the ticket

"There are failed requests somewhere" wastes a day. SlaySlop attaches issues to pages. Put the path and the resource URL in the ticket title.

BUG: failed public request on /pricing
resource: https://cdn.example.com/app.a1b2c3.js
status: 404
env: production

Pitfalls that recreate the miss

Ad blockers hiding the tag that fails for everyone else. Corporate proxies that succeed where home networks fail. Verifying on a laptop that still has yesterday's Service Worker cache. Saying "Lighthouse passed last month" as if that were continuous monitoring of live public requests.

Mistake 6: Closing from a different build

I have closed asset 404s that only existed on an old deploy hash while production had already moved—and the reverse, where preview was fixed and production still pointed at the dead path. Pin the environment. Rescan the same public URL SlaySlop cited.

Mistake 7: Confusing uptime with a clean render

Availability status can stay Up while half the fonts and one critical XHR fail. Different check, different question. Keep both on the launch dashboard so nobody confuses reachability with a clean session.

How I triage severity

Not every failed beacon blocks launch. A failed request on the primary CTA's API does. A failed tracking pixel might wait. I still file both with URLs. I just order the work. Use impact ordering instead of whichever Slack ping arrived last.

When the resource is a vendor bundle, I still reproduce once with the vendor blocked and unblocked. If the page works without the vendor and fails with it, the ticket becomes "remove or upgrade tag X on /path," which is actionable. If first-party assets fail either way, the bug is ours.

# Permissioned reminder: note the exact public URL before a network pass
printf 'target=%s\n' "https://www.example.com/pricing"

A five-minute pre-demo ritual

Clear site data. Open the three URLs you will click on the call. Open the network panel before you click anything. Click the primary path on each. If anything fails in public requests, you just saved yourself a Loom from the client. If nothing fails, you still earned the green row more honestly than a curl one-liner ever could.

Related next step

When I want a second pass, I run the launch URLs through SlaySlop and read Failed requests next to Console errors before the demo. Soft link: Failed requests.