[ http-status:// ] experimental
Paste an HTTP status code + the context (what you called, what came back). Get the actual cause (not just "401 = unauthorized"), common pitfalls, and two debug next steps.
// system prompt
You diagnose HTTP errors in context. User provides status code + context about what they were doing. Output: What the status code means: <one short line, no padding> Likely actual cause (given your context): <2-4 sentences naming the most probable cause for THIS situation, not generic causes> Three patterns that produce 4xx/5xx in your situation: 1. <pattern> — <when it happens> 2. <pattern> — <when it happens> 3. <pattern> — <when it happens> Debug next steps (do these in order): □ <concrete step> □ <concrete step> Rules: - Lead with the LIKELY cause given the context, not the textbook definition. - For 401: distinguish missing token, expired token, wrong token format, wrong audience claim, clock skew, scope mismatch, IP allowlist. - For 403: distinguish role-based (token valid but lacks permission), resource-level (you can't see this specific record), and CORS-mistaken-for-403. - For 404: distinguish missing record vs wrong URL pattern vs path-rewriting middleware. - For 429: distinguish per-IP, per-token, per-account, burst vs sustained. - For 5xx: distinguish gateway timeout, internal exception, deploy in progress, dependency outage. - Context-specific: if user mentions Lambda / Cloudflare / Vercel / Kubernetes, suggest platform-specific causes (IAM role expiry, Worker timeout, etc). - Debug steps must be CONCRETE. "Check the logs" is not a step. "Open CloudWatch, filter on `requestId`, look at the line just before the response status" is a step.
⚡ powered by Cloudflare Workers AI · quota deducted on success
// output
// sample output
What the status code means: 401 Unauthorized — the request had no credential, or the credential was rejected.
Likely actual cause (given your context):
You said it worked from your laptop but not from the Lambda, and was fine yesterday. The strongest signal is "worked yesterday, broken today, Lambda only" — that pattern most often points to a credential the Lambda fetches that has now rotated or expired. The next most likely is a clock-skew issue (Lambda containers vs your laptop) if the token is JWT.
Three patterns that produce 401 in your situation:
1. The Lambda fetches an IAM-issued credential at cold start (e.g. via STS AssumeRole or instance metadata) and caches it for the life of the container. If the role's session token has rotated, the cached one is now rejected. Cold-restarting the Lambda would fix it.
2. The bearer token / API key the Lambda uses is in Secrets Manager / Parameter Store and was rotated yesterday — the Lambda is still reading the old version because it caches secret values in memory across invocations.
3. JWT clock-skew: the Lambda container's clock drifted (rare but possible) and the token's `nbf`/`exp` claims fail the API's tolerance window. Less likely but worth a 30-second check.
Debug next steps (do these in order):
□ In the Lambda console, hit "Test" with a manual invocation right after redeploying (forces a cold start). If it works after a fresh deploy, the cached-credential pattern (#1 or #2) is the cause — fix is to either re-fetch the credential on every invocation, or invalidate the cache on 401.
□ Add `console.log("token first 20 chars:", token.slice(0, 20))` to the Lambda just before the API call and compare to the token your laptop is using. If they're different, the Lambda is reading from a different secret source than you think. If they're the same, the Lambda's clock is the culprit — `console.log("Lambda time:", new Date().toISOString())` next to confirm. // powered by cloudflare workers ai · quota deducted on success ← back to catalog