# API Monitoring — Routebase > Routebase builds API monitoring on your published OpenAPI contract, so every scheduled check validates the live response against the version your environment is pinned to. Canonical page: https://routebase.dev/api-monitoring/ API monitoring usually stops at the pulse, so every check stays green while a field quietly changes type and the first person to notice is a consumer with a broken integration. Routebase treats the published OpenAPI contract as the thing to monitor. A scheduled check therefore asks whether the endpoint answered and whether the response still matches the version that environment is pinned to. A deviation that keeps showing up becomes a drift event with a first-seen date, an observation count and a field-level diff, and it stays out of your uptime figure because nothing went down. Alert policies with cooldowns, incidents and maintenance windows carry the operational side, while monitors generated from the spec wait for a deployment instead of paging anyone. Because the same contract also drives your docs, mocks and tests, API monitoring closes the loop after the release. ## Every check validates the response against the contract A monitor linked to a documented endpoint validates each response against the version its environment is pinned to, and it falls back to the latest published version where nothing is pinned. - Missing required field, type mismatch, extra field and format mismatch, each with a severity - Warn mode records the drift and keeps the check green, Strict mode fails the check - The version checked against is recorded per check, so a re-pin never relabels history ## Drift is a record you can act on, not an incident A deviation that keeps appearing becomes a drift event with a first-seen date, an observation count and a lifecycle you acknowledge and close, and it resolves itself when a later check matches again. - Field, change, expected and received for every deviation, with not present instead of null - The failing request and the first 4 KB of the response are kept with the event - Credentials never reach that record, because secret variables are not substituted into it - A drifting endpoint still answers with a 200, so it never counts against your uptime ## Alerts that reach the right people without the noise An alert policy holds up to four rules for downtime, latency, error rate and schema drift, each with its own cooldown, and the most specific assignment wins. - Assign a policy to an environment, a specification or a single monitor - Incidents open after consecutive failures and name the policy that triggered them - Maintenance windows keep the checks running while no incident opens - Slack and Microsoft Teams as first-class targets, plus email and the in-app center ## Monitors that come from the spec and wait for the deploy A four-step wizard generates monitors from the endpoints of a specification and skips the ones already covered, and a coverage card shows which endpoints still have none. - A monitor whose endpoint has never answered waits, raises no alert and stays out of the uptime figure - Environment variables and auth apply to every check automatically, from Bearer to OAuth2 - Promote a version to an environment from your pipeline, and its monitors validate against it ## Frequently asked questions ### What is contract drift and how does API monitoring catch it? Contract drift is what happens between two deploys, when your specification still promises one shape and production has started returning another while every uptime check stays green. Every monitor check that gets a response validates it against the contract the environment is pinned to. A deviation that keeps showing up becomes a drift event with a field-level diff. ### Which spec version do the monitors validate against? A monitor validates against the version its environment is pinned to, which is the contract that environment is expected to fulfil. Where nothing is pinned, for an unpinned environment or a monitor pointed at a raw URL, validation falls back to the latest published version. The version used is recorded at check time, so a later re-pin does not relabel history. ### Does a drifting endpoint count as downtime? No. A drifting endpoint still answers with a 200, so counting it against uptime would hollow out the number you publish to your customers. Drift events have their own lighter lifecycle with acknowledge and resolve. The exception is a monitor in Strict mode, where error-severity drift fails the check itself and can open an incident. ### Can I run API monitoring from CI? Monitors run hosted on their own schedule, from every 30 seconds to once a day, so nothing in your pipeline has to stay alive for them. Your pipeline promotes a version to an environment with the CLI or the GitHub Action after a deploy, and the monitors of that environment validate against the new contract from the next check. The tests that belong in CI cover the time before the release. --- [Routebase](https://routebase.dev/) — [Sign up](https://app.routebase.dev/): Every account starts with a 14-day Pro trial — no credit card required.