# Design-First API Monitoring: Monitors That Wait — Routebase

> What changes when the contract exists before the service, why an unshipped endpoint must not report zero percent uptime, and what coverage does and does not tell you.

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

In a design-first workflow the contract exists before the implementation does. That changes what monitoring can be, because the list of things worth watching is already written down before there is anything to watch.

## Monitors can exist before the service

If the specification lists twenty endpoints, twenty monitors can be provisioned from it in one step, long before the service answers any of them. That is useful for two reasons.

It removes the step everybody forgets, which is going back to add monitoring after the launch, when the launch is over and attention has moved on. And it makes the gap visible in the other direction, because a monitor waiting for an endpoint is a visible reminder that the endpoint has not shipped.

None of it works if those monitors are red in the meantime.

## Why waiting is a state and not a failure

A monitor whose endpoint has never been deployed has not measured anything. Reporting that as downtime is wrong in three separate ways.

It **corrupts the uptime figure**, because a service that does not exist yet cannot have a 0 percent availability record that later gets averaged into a real one. It **fires alerts nobody can act on**, and repeated alerts nobody can act on are how a team learns to dismiss the channel. And it **hides the real signal**, because the day that endpoint ships and genuinely breaks, its monitor was already red.

Two waiting conditions are worth separating, because they are fixed by different people.

| Waiting on | Cause | Who resolves it |
|---|---|---|
| Deployment | The endpoint exists in the contract and the environment does not serve it yet | Whoever ships the service |
| A parameter value | The target URL still contains an unresolved placeholder such as `{id}` | Whoever configured the monitor |

Both should be visible, neither should alert, and neither should touch the uptime number. The second one deserves a warning somewhere in the interface, because a monitor that has silently never run is worse than one that runs and fails.

## Coverage, and what it does not say

Coverage is the share of endpoints in a specification that have a monitor. It exists to answer one question, which is whether anything shipped without anyone thinking about it.

It is a completeness measure and not a quality one, so read it with two caveats. An endpoint with a monitor that only checks the status code counts as fully covered while validating nothing about the response. And a monitor pointed at the same URL by hand usually does not count at all, because nothing links it back to the endpoint in the contract it is supposed to be watching.

The useful second number sits next to it. Coverage asks how many endpoints have a monitor, while the share of those monitors that can actually validate a response asks how many of them are checking anything beyond availability.

## What should happen when you publish

Publishing a version is the moment monitoring most often falls behind, because the specification grows and the monitors do not.

Two behaviours keep them in step, and a team should pick one on purpose. Either new endpoints get a monitor created automatically in the target environment, which keeps coverage at 100 percent and occasionally produces a monitor nobody wanted. Or the gap is reported and somebody decides, which keeps the set deliberate and depends on the report being read.

The second thing that should move at publish is the baseline. If the environment now serves 2.1, validation should compare against 2.1, and a pin left behind on 2.0 makes the whole drift setup quietly useless. [Running multiple API versions](/guides/api-versioning/running-multiple-api-versions/) covers how those pins behave when several versions are live at once.

## In Routebase

Monitors are generated from a specification through a four-step wizard that picks the specification and environment, selects the endpoints, sets defaults for the batch and reports what it created. It is idempotent, so endpoints that already have a monitor are marked and skipped rather than duplicated.

_Screenshot: The wizard reads the endpoints from the contract, marks the ones that already have a monitor as skipped, and asks for a value for every path parameter it cannot fill by itself._

A monitor whose endpoint has never answered reports as waiting for deployment, raises no alert, opens no incident and is excluded from every health figure, and it activates itself the moment the endpoint responds. The [API-first development](/api-first-development/) page shows the same waiting stance across the mock, the tests and the monitors. A monitor with an unresolved path parameter reports as waiting for parameters and runs no checks at all, so nothing is written to its history.

The dashboard carries a coverage card per specification with a shortcut that fills the gaps, and a project setting decides whether publishing a version creates monitors for new endpoints or just reports them. See [Coverage](https://docs.routebase.dev/coverage/) and [Environments](https://docs.routebase.dev/environments/).

## Frequently asked questions

### Can you set up monitoring before an API is deployed?

Yes, and design-first teams should, because the contract already lists every endpoint that is going to exist. The condition is that a monitor for an endpoint nobody has shipped yet must report that it is waiting rather than reporting an outage. A monitor that is red for three weeks before launch is a monitor everybody has learned to ignore by launch day.

### What is monitoring coverage?

Coverage is the share of a specification's endpoints that have a monitor attached to them, which answers the question of whether anything shipped without being watched. It is a completeness measure rather than a quality measure, so an endpoint with a monitor that only checks the status code counts as covered while validating nothing about the body.

### What happens to monitoring when you publish a new API version?

Two things should happen. New endpoints in that version need monitors, either created automatically or reported to you as a gap. And the contract that existing monitors validate against should follow the version the environment is now serving, so that validation keeps testing the current promise rather than an old one.

### Should every endpoint have a monitor?

Every endpoint should be accounted for, which is not the same as every endpoint being checked every minute. Cover the paths that carry the product at a short interval and the long tail at a long one. Then make a deliberate decision about the rest, rather than leaving it to whoever was setting monitors up that afternoon. What you want is no endpoint that nobody has thought about.

---

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