Check whether the gateway is down
When requests fail, the first question is whose problem it is: the gateway, a provider behind it, or the key and request themselves. Since 0.3.0 the gateway answers that question directly, starting from the base URL already in the SDK configuration.
Persona: Developer calling the gateway.
Estimated time: under a minute for the two checks; a few minutes when the trail leads into Request Logs.
Step 1: open the base URL
Paste the gateway base URL into a browser, or run:
curl -s https://<gateway-hostname>/
No API key is needed. The JSON document that comes back separates the cases:
| Answer | Meaning | Next move |
|---|---|---|
status: serving | The gateway is up with routes deployed. The problem is further along: a provider, the key, or the request. | Step 2 |
status: not_serving | The gateway is up but has nothing configured to serve. Not a key or request problem. | Raise it with the platform operator; requests are not answered until configuration is applied. |
status: unknown | The gateway is up but cannot currently read whether routes are deployed. | Treat as serving and continue; mention it if a support ticket follows. |
| No response at all | The data plane itself is down or unreachable. | Check DNS and network, then raise it with the platform operator. |
Every state other than serving carries the sentence "This is not a problem with your API key or your request." in its message, which is exactly the doubt it exists to remove. The full field reference is in Gateway behavior.
Step 2: ask which provider is failing
With the gateway serving, the next suspect is a provider behind it. GET /v1/status takes the same API key used for inference:
curl -s https://<gateway-hostname>/v1/status -H "Authorization: Bearer $TARS_API_KEY"
The providers list reports reachability derived from the requests this gateway actually forwarded, not from probes, so it reads differently from a health check:
reachable: truewith a non-zerofailurescount means traffic is flowing and some of it failed; look atlast_failure_code.reachable: falsemeans every observed request to that provider failed in the window. The provider, not the gateway, is the problem.reachable: nullmeans no traffic was observed in the window: no evidence either way, not health.
Two caveats before quoting the numbers: the reply is per replica (the replica field names which pod answered, and another pod behind the same load balancer can answer differently), and the window is short and resets when configuration is pushed (observation_window). Field-by-field detail is in Gateway behavior.
Step 3: rule out the key and the model
Both endpoints reporting healthy moves the question to the key and the request:
GET /v1/modelsreturns exactly the models the calling key can reach on this data plane. An empty or short list means configuration, not availability.- A
403withcategory: hostname_not_selectedmeans the key does not belong to the project served on this hostname. Retry against one of the hostnames in the response'syour_hostnameslist instead of guessing; the format is documented in Gateway behavior.
Step 4: look at the request that failed
For a failure that already happened, the per-request record is the authority: find it in Request Logs by its X-Request-ID, as described in Monitor traffic and usage. Quote the correlation ID, and the reference_id from a 403, in any support ticket.
Both status endpoints are answered by the data plane itself, so they keep working during a management plane outage, and both accept only GET and HEAD.
Where to go next