Is it down, or is it me?
When requests start failing, the first question is whether the problem is yours or ours. This page tells you how to find out in under a minute.
Check the status page first
Open /status. No sign-in needed, which matters: if the problem is on our side you may not be able to log in at all.
You will see one line for the service overall, then one line per model provider.
| What it says | What it means |
|---|---|
| All systems operational | Everything is working. The problem is likely in your request. Read on. |
| Some providers are unavailable | One provider is having trouble. Your requests still work, they are served by another provider automatically. |
| No providers are currently available | Nothing can be served right now. Wait, and retry. |
| The gateway is not accepting requests | The service itself is down. Wait, and retry. |
Each provider shows one of three states:
- Operational — working normally.
- Degraded — still serving, but its last health check failed. Expect slower replies or occasional errors.
- Down — switched off by us, usually because it was failing badly. Requests go to another provider instead.
A provider being Down does not mean your requests fail. LIBRA falls back to another provider that can serve the model you asked for. A request only fails when no provider can serve it.
If the status page says everything is fine
Then the answer is in the error you got back. Every failure includes a type you
can look up on the Errors page, and a request_id.
The four most common, and what they really mean:
401— the key is wrong, disabled, deleted or expired. Check you are sendingAuthorization: Bearer libra_sk_...and that the key still exists under API Keys.402— your organisation is out of credit. Someone with admin rights needs to top up from the Credits page.403 model_not_allowed— the key is fine, but its guardrails do not permit that model. Check the key's allowed models.429— too many requests too quickly. Slow down and retry.
Always keep the request id
Every response, successful or not, carries a x-libra-request-id header, and
failures repeat it in the body as request_id. It looks like req_b0fb5ca486b7.
Quote it when you ask for help. With it we can find your exact request in the logs in seconds. Without it, we are guessing.
Watching the service automatically
If you want your own monitoring to track us, poll GET /api/status. It needs no
key and is cached for 15 seconds, so checking every 30 seconds is plenty.
curl -s http://43.173.12.157/api/status
The status field is operational, degraded or down. Alert on down.
For a stricter check, GET /healthz returns 503 when the gateway cannot serve
traffic at all, which is the condition worth paging someone about.