Debugging anti-bot 403s in DevOps
# the problem
A curl-based monitor or vendor health check that worked for months suddenly returns 403. You cannot tell whether the vendor is down, rotated an API, or just tightened bot management — and every layer of your dashboard says the same unhelpful thing.
# what recurl does
Run the request through recurl with --recurl-debug. It runs plain curl first, and if it sees a 403/429/challenge it prints exactly which layer escalated, which fingerprint it used, and what each upstream attempt returned. You get a definitive answer: fingerprinting, JS challenge, or genuine outage.
# how to do it
Step by step
- 1
Reproduce the failing request with recurl --recurl-debug <url> to see the per-layer trace.
- 2
Read the trace: layer=curl_engine status=403 means the plain request was blocked, not that the host is down.
- 3
If impersonation or js_preflight returns 200, the host is up and the 403 was bot management — swap the monitor to recurl.
- 4
If every layer still fails, escalate as a real upstream outage with the trace attached as evidence.
Related
See the escalation architecture, browse more use cases, or follow a guide.