An API fails on the server's side

The row’s figure gives the numbers in a few words, such as 8 of 130 calls failed on the server side in 15 min.

What it means#

Calls to an API version fail on the server’s side: the gateway or the upstream behind it answered with an error. Callers who sent a bad request don’t count, so the problem is about your side of the API.

What raises it#

The hub checks the API version’s calls in each environment where it is deployed. The problem is raised when at least 5 % of at least 20 calls in 15 minutes failed on the server’s side, and it becomes an error from 25 %. A version that is no longer deployed raises nothing. The detail gives the integration behind the API to readers who may read it. The problem needs the hub’s metric store, which every installation has unless it was set up without one.

What to check#

See the API’s calls, failures and response times:

$ weikio metrics --api <project>/<api>@<version> --env <environment> --since 1h

Open the failed calls’ traces, which continue into the integration behind the API:

$ weikio traces --api <project>/<api>@<version> --env <environment> --errors --since 15m

Read the version’s routes and upstreams:

$ weikio describe apiversion <project>/<api>@<version>

How to fix it#

When the upstream is your own integration, its traces and logs give the cause, and its own problem rows often show it too. When the upstream is another system, check that it answers at the address the version’s cluster names. A version that broke the API can be rolled back to the definition it served before:

$ weikio api rollback <project>/<api>@<version> --env <environment>