Operational Troubleshooting

Summary

Operational guide for diagnosing live AtlasBurn issues — guardrail kills, stuck KV flags, missing telemetry, and edge-proxy errors. For SDK install and framework-specific setup questions, see SDK Integration or Proxy Troubleshooting.

My AI calls are being blocked (429 or 403)

A SUSPENDED flag is active for your org or for the feature making the call. SDK users get a 429 with an x-atlasburn-blocked header; the edge proxy returns a 403.

1. Open the dashboard → Forensic Ledger and find the kill event. It will name the triggering layer (Financial Limits, Dumb Loop, Smart Loop, RPS Burst, Premium Concentration).
2. Fix the root cause in your agent. The ledger shows the trigger, the observed value against the limit and, for loops, the feature that looped. AtlasBurn never stores prompts, so check that feature's logic and retry handling.
3. Click Resume to clear the KV flag instantly, or wait for the 2-hour TTL to auto-expire. See Auto-Recovery & Manual Override.

Calls from one feature got slow (about 2 seconds apart)

That feature is throttled. On Throttle mode, or as the first step on Kill Switch, AtlasBurn slows a looping feature instead of blocking it. The Safety Guardrails page shows the throttled feature and when it speeds back up. On Kill Switch it is blocked only if the loop is still running 60 seconds later or costs more than your loop-block limit (see How each tier responds).

Only one feature is blocked, the rest work

That is expected. Loop guardrails pause only the feature that looped (see What gets blocked). Resume that feature from its own button on Safety Guardrails, or let its timer run out. If every untagged call is blocked, the loop was in untagged traffic: tag your features with atlasburnFeature() so the next one stays contained.

The kill flag won't clear after I clicked Resume

Resume (POST /api/guardrails/enforce with action: "ACTIVE") is idempotent and propagates to all Cloudflare edges in under a second. If traffic is still being rejected:

• Check that the request really is hitting the proxy at proxy.atlasburn.com and not a stale cached baseURL.
• Confirm the AtlasBurn-API-Key header is set. Requests without it are rejected as unauthenticated, not as guardrail kills.
• Re-trigger Resume. The dashboard surfaces the KV response — a 404 means the flag is already gone and the issue is elsewhere.

No telemetry events are arriving

• Using the Edge Proxy? Confirm baseURL points to https://proxy.atlasburn.com/<provider>/v1 and the AtlasBurn-API-Key header is set on every request.
• Using the SDK? Confirm initAtlasBurnAuto runs at boot (see SDK Integration) and that the process actually has time to flush before exit.
• Check the Forensic Ledger filter — events default to the last 1 hour.

Guardrail keeps tripping on legitimate traffic

Tune the layer thresholds from Settings → Guardrails. Common cases:

• Batch jobs — raise the Layer 4 RPS ceiling or schedule the job with a dedicated key whose limits match its burst profile.
• Identical prompts by design (eval suites, prompt-regression tests) — add the fingerprint to the Layer 2 allowlist.
• Premium-only workloads — disable Layer 5 for the relevant API key.

Latency increased after enabling the proxy

The edge proxy adds <5ms in steady state (KV read + forward). If you see more:

• Verify your client is keeping connections alive (keep-alive headers).
• Check the request is hitting the nearest Cloudflare PoP — not a custom region pinned far from your runtime.
• Inspect the response cf-ray header to confirm edge termination.

Self-hosted proxy isn't reading KV

Re-check wrangler.toml:

[[kv_namespaces]]
binding = "GUARDRAIL_FLAGS"
id = "<your-kv-namespace-id>"

The binding name must be GUARDRAIL_FLAGS — the worker looks up that exact identifier. After editing, redeploy with npx wrangler deploy.

Still stuck?

Open a support ticket from the dashboard with the org id and a sample kill event id — we can replay the full guardrail evaluation against your event stream.