LLMPing LLM API status and debugging toolkit

Debugging guide

How to debug LLM API errors without guessing.

Start by separating provider incidents from request shape, key scope, quota, model access, runtime, CORS, and network path. Most incidents become easier once you prove the same request with a minimal cURL command.

Explain an error Generate cURL

First checks

Use this order during an incident

  1. Check the provider-owned status page for active API, model, billing, or console incidents.
  2. Run a generated cURL command outside your app with the same key and model.
  3. If cURL fails with 401 or 403, verify key scope, project, organization, and model access.
  4. If cURL fails with 429, inspect billing, quota, token limits, and request concurrency.
  5. If only browser calls fail, suspect CORS or preflight instead of provider downtime.
  6. If only production fails, compare environment variables, outbound network rules, and region.

Common symptoms

What the error usually points to

  • 401: missing, invalid, expired, or wrong-project API key.
  • 403: permission, model access, region, policy, or organization restriction.
  • 429: rate limit, token throughput, quota, billing, or concurrency limit.
  • 5xx: provider, gateway, upstream model, or temporary capacity issue.
  • CORS: browser security policy, not proof that the API is down.

Reliable proof

Why cURL matters

cURL removes your frontend framework, browser CORS behavior, extensions, and most app code from the test. If cURL works but your app fails, debug runtime configuration. If cURL fails with the same status code, debug key, quota, model, endpoint, or provider status.

For production monitoring, a browser tool is not enough. You need server-side checks, controlled regions, alert delivery, and historical failure records.