Skip to content
API monitoring

You got a 200,but was the answer right?

An API can return 200 and still hand back an empty list, an error buried in the body, or stale data. Chekaav checks the content of the response as well as its availability, and treats a missing expectation as an outage.

Free plan: 3 monitors and one vantage point · 14-day Pro trial

What gets checked

Any condition you define fails the check when it does not hold.

  1. Status code

    You name the codes that count as success; anything else is a failure.

  2. Response time

    Set a ceiling, and a slower response is recorded as a failure.

  3. Response content

    Assert that text is present, absent, exactly equal, or matches a pattern.

Assertions on JSON fields

Go straight to the field instead of searching the whole body as text.

Field paths

Paths such as $.status or $.data.items[0].id, with dot access and array indexing.

Four modes

The field exists, equals a value, does not equal it, or contains it.

A real example

"$.status equals ok" means a 200 whose internal state has gone to degraded still opens an incident.

Non-JSON responses

If the body is not valid JSON, or the path is missing, the failure reason says exactly that.

The request we send

Shaped the way your service expects, not a generic probe.

GET or POST

For POST you set the body and its content type.

Custom headers

Whatever your API needs; header values are never shown back in results or evidence.

Bearer token

Stored and never returned by the API — you only see that one is set.

TLS and redirects

Following redirects and certificate verification can each be turned off, for internal certificates.

What you get when it fails

Enough that you should not have to reproduce it yourself.

A specific reason

For example "JSON value did not match" or "unexpected status code", not just "failed".

Part of the body

For text responses, an excerpt of the body at the moment of failure is kept.

Safe response headers

A short allowlist such as content type and request id; sensitive headers are never stored.

Per-region results

You can see whether one vantage point saw it or all of them did.

Where this stops

No multi-step flows

Each monitor sends one request. "Log in, take the token, then call" is not supported yet.

Content checks start at Starter

On the free plan you can create an API monitor and see status code and response time; custom headers and bodies, tokens, JSONPath and advanced content matching come with the Starter plan.

Do not point it at a mutating endpoint

The monitor repeats the same request on a schedule, so choose one that is safe to read.

We watch from outside

Chekaav connects like a consumer of your API; it does not read your server's logs or internal metrics.

Try it against a real endpoint

Create an API monitor, define a content assertion, and see what the result and the failure evidence look like.

Create a free account