# Types of API Monitoring Checks: Health, Synthetic, Contract and SLA — Routebase

> What a health check proves, what a synthetic call adds, what contract validation catches that neither does, and how to pick intervals and timeouts that are worth their traffic.

Canonical page: https://routebase.dev/guides/api-monitoring/types-of-api-monitoring-checks/
Chapter 1 of 9 · API Monitoring · Last reviewed 2026-09-13 · The Routebase Team

Everything that calls a live API on a schedule gets called monitoring, and the differences between those calls decide what you will find out. This chapter separates them by the question each one answers.

## Four kinds of check

| Check | Answers | Misses |
|---|---|---|
| Health endpoint | Is the process running | Almost everything, when the handler touches no dependency |
| Synthetic call | Does a real endpoint work end to end, with real credentials | Anything about the shape of the answer |
| Contract validation | Does the body still match what the contract promises | A field that keeps its shape and stops changing value |
| SLA measurement | What number do we report at the end of the month | Nothing, because it is a measurement rather than a detector |

The four are layers rather than alternatives. Each one rides on the request the one above already made, so adding the next layer usually costs configuration rather than traffic.

## Health checks, and the trap in them

A health endpoint is the cheapest check to set up, and the easiest one to make meaningless.

The trap is depth. A handler that returns `{"status":"ok"}` without touching anything proves that the web server is accepting connections, which is true of a service whose database credentials expired an hour ago. Every dependency the check skips is a dependency it cannot report on.

A deeper health endpoint touches the database, the queue and the upstream providers before answering, so a failure means something. That makes it slower and gives it a second job, because a deep check under a one-minute schedule is a load test of your dependencies that runs forever. Two rules keep it useful.

Separate liveness from readiness, so the orchestrator gets the cheap answer and your monitoring gets the honest one. Then give the deep check a longer interval than the shallow one, because you do not need a full dependency sweep every thirty seconds.

## Synthetic checks against real endpoints

A synthetic check is a scripted request to an endpoint your consumers actually use, sent on a schedule with the credentials a consumer would carry.

Its advantage over passive telemetry is coverage of the quiet paths. An export endpoint that three customers call on Mondays is invisible in traffic dashboards, and a synthetic check notices when it breaks on a Wednesday. Three design decisions make the difference between a useful set of them and an expensive one.

**Pick endpoints that mean something.** Check the ones that touch the database, the queue and the upstream provider, because those are the ones that break. A list endpoint that reads from cache is not representative of your API.

**Keep them read-only.** A monitor that creates data creates data every minute, forever. Where a write path has to be covered, give it a dedicated account and a cleanup path, and run it far less often than a read.

**Spend the interval budget deliberately.** Every check is a real request, so the total cost is the number of monitors multiplied by their frequency. Concentrate the fast intervals where the minutes matter.

## Contract validation on the same response

The response body is already in hand once the synthetic check has run, so validating it against the contract costs almost nothing beyond the decision to do it.

This is the layer that catches the failures a status code cannot express. A field that went missing, a type that changed from a string to a number and an enum that grew a value the contract never listed are all served with a `200`. All three break a consumer. [Contract drift](/guides/api-monitoring/api-contract-drift/) covers the mechanics and what to do with what it finds.

One decision has to be made here rather than later, which is what the response gets compared against. Validating against the newest draft of your specification reports drift every time somebody edits a schema. Validating against the version this environment is supposed to serve reports it only when production and its promise disagree.

## Intervals and timeouts

Two numbers decide both the cost and the sensitivity of your setup, and both are usually left on the default.

The **interval** decides how quickly you can possibly know. An outage cannot be detected sooner than the next scheduled check, and an alert rule that waits for three consecutive failures multiplies that. At a five-minute interval, a rule like that takes a quarter of an hour to fire, which is fine for a reporting API and much too slow for a payment path.

| Endpoint | Reasonable interval | Reason |
|---|---|---|
| Login, checkout, payment | 30 seconds to 1 minute | Minutes of silence are already expensive |
| Core read paths | 1 to 5 minutes | The bulk of consumer traffic |
| Long tail and internal tools | 15 to 30 minutes | Nobody is waiting on the news |
| Deep dependency sweep | 15 minutes or more | It costs real work to answer |

The **timeout** decides what counts as a failure rather than a slow success. Set it above your worst legitimate response time and below the point where a caller would have given up. A timeout of sixty seconds on an endpoint that answers in eighty milliseconds cannot tell the difference between slow and dead.

## What none of them catch

Three failure modes survive every check in this chapter, and it is worth knowing them before you trust a green dashboard.

A value that keeps its shape and stops changing is invisible to schema validation, which [data freshness](/guides/api-monitoring/api-data-freshness-monitoring/) covers. A response that is correct for the monitor's account and wrong for somebody else's needs more than one identity to detect. And a check that runs from one place tells you nothing about a consumer on the other side of a broken peering link.

## In Routebase

A monitor is a scheduled HTTP check against one target, which is either a URL you type or an endpoint from your specification. You choose the method from the seven HTTP verbs, the status code that counts as healthy, an interval from the presets between 30 seconds and an hour, and a timeout of up to 120 seconds.

_Screenshot: Every check keeps its own timing breakdown across DNS, connect, TLS, first byte and download, so a slow check can be blamed on the network or on the server rather than on either by guess._

Linking a monitor to an environment applies that environment's variables and authentication to every check, so a target written as `{{baseUrl}}/carriers` resolves and the request carries real credentials. **Generate from Spec** provisions monitors for a whole specification through a four-step wizard, and it is idempotent, so re-running it after adding endpoints fills only the gaps. You can also create one straight from the API designer by right-clicking an endpoint.

Schema validation is a per-monitor setting with three modes, defaulting to **Warn**. See [Monitors](https://docs.routebase.dev/monitors/) for the full configuration and [Schema Drift](https://docs.routebase.dev/schema-drift/) for what validation compares.

## Frequently asked questions

### What is an API health check?

A health check is a request to an endpoint whose only job is to report that the service is running. A shallow one returns a fixed response from a handler with no dependencies, so it proves the process is alive and nothing else. A deep one touches the database, the queue and the upstream providers before answering, which makes it far more useful and far more likely to be slow.

### What is synthetic API monitoring?

Synthetic monitoring sends scripted requests to a live API on a schedule and records the result, rather than waiting for real traffic to reveal a problem. Its advantage over passive telemetry is coverage, because an endpoint nobody has called since Tuesday still gets checked every few minutes. Its cost is that every check is real traffic against real infrastructure.

### How often should an API monitor run?

Match the interval to how fast you need to know and what the check costs. One minute is reasonable for the handful of endpoints that carry the product, while five or fifteen minutes is plenty for the long tail. A one-minute interval across two hundred endpoints is a load pattern rather than a monitoring strategy, so treat the interval as a budget you are spending.

### Should API monitors write data?

Prefer read-only checks, because a monitor that creates an order creates one every minute forever. Where a write path genuinely has to be covered, give it a dedicated account, a cleanup path and a lower frequency, and accept that you are running a scheduled test rather than a monitor. The alternative is a production database slowly filling with synthetic rows nobody claims.

---

[Routebase](https://routebase.dev/) — [Sign up](https://app.routebase.dev/): Every account starts with a 14-day Pro trial — no credit card required.