API Monitoring Guide
Get alerted when the Netlify API has issues before your deploys fail, your CI/CD stalls, or your live site starts serving errors. Know the Netlify API status in real time, not 15 minutes later.
Netlify hosts millions of sites and runs builds, edge functions, and a global CDN. When the REST API at api.netlify.com/api/v1 degrades, your deploy pipelines and automations break; when the edge has an incident or a deploy ships bad code, your visitors see it directly.
This guide covers everything you need to monitor Netlify API status: which endpoints to track, how the 500 requests/minute API limit and the deploy limits (3/min, 100/day) work, how to tell an API problem from a site problem, and what to do when something breaks during a deploy.
Netlify maintains a status page at netlifystatus.com covering the API, CDN, builds, and DNS. It's useful for confirming a platform-wide incident, but relying on it alone leaves real gaps.
External synthetic monitoring catches Netlify API and site issues in 1-2 minutes, not 10-15. That head start lets you roll back a bad deploy, pause your pipeline, or investigate before visitors are impacted.
"Netlify" spans several surfaces that fail independently. Knowing which you depend on tells you what to monitor.
Authenticate to the API with a personal access token sent as Authorization: Bearer. Create a dedicated token for monitoring so you can revoke it independently. Your live-site checks need no auth at all.
The deploy state field is your best build-health signal: ready means the latest deploy is live and serving, while error means a build failed (your previous deploy stays live). Monitoring the latest deploy state catches CI/CD failures the moment they happen.
Each endpoint below tests a different layer. Monitoring several lets you pinpoint whether a problem is the API, a deploy, a function, or the live edge.
GET https://api.netlify.com/api/v1/sites?per_page=1
Sites list. A lightweight auth + API health check: confirms the REST API is up and your token is valid. Use ?per_page=1 to keep it cheap. Make this your primary Netlify API health monitor.
GET https://your-site.netlify.app/
Your live site. This is what visitors actually hit — it tests the CDN edge and your deployed code together. Validate the body for known content so a blank or error page doesn't pass as a 200.
GET https://api.netlify.com/api/v1/sites/{site_id}/deploys?per_page=1
Latest deploy. Returns the most recent deploy; check the state field. Alert if it's error (failed build) rather than ready. Catches CI/CD failures before someone notices the site is stale.
GET https://your-site.netlify.app/.netlify/functions/health
Netlify Function. If you run serverless functions, monitor a health route. Functions can fail on cold starts, timeouts, or runtime errors independently of the static site. Validate the body to catch a 200 carrying an error payload.
GET https://your-custom-domain.com/
Your custom domain. Monitor the production domain your users actually visit, not just the netlify.app subdomain. Catches DNS, SSL/TLS, and custom-domain routing issues that the .netlify.app URL would miss.
Rate limit note: The Netlify API allows ~500 requests/minute, so a few checks per minute is negligible. Deploys are far stricter (3/min, 100/day) — but monitoring only reads deploy state, it never triggers deploys, so it won't consume your deploy budget.
Netlify's rate limiting can make a healthy API look broken from your pipeline's side — especially around deploys. Understanding it is essential for both robust automation and accurate alerting.
Most API endpoints allow up to 500 requests per minute. Exceed it and Netlify returns HTTP 429. The response headers report your current limit status so you can back off proactively.
Triggering deploys through the API is capped at 3 per minute and 100 per day. A misconfigured CI loop or a deploy hook hit repeatedly can exhaust this and block legitimate deploys with a 429 for the rest of the window or day.
Health checks only read (sites, deploy state, live pages); they never create deploys. A handful of GETs per minute is a tiny fraction of the 500/min budget and touches the deploy limit not at all. Keep automation tokens separate from monitoring tokens so a runaway pipeline can't 429 your health checks.
A 429 means you're throttled — back off and check whether it's the general or deploy limit. A 503 or widespread timeouts point to an actual Netlify incident, and a 5xx on your live site (with a healthy API) usually means a bad deploy or function. UptimeSignal records status codes and response times so you can tell these apart instantly.
Your deploys and sites run on Netlify. Monitor them yourself.
Get alerted when the API, a deploy, a function, or your live site start failing — before visitors hit a broken page. Free for 25 endpoints, checks every 5 minutes.
Monitor Netlify API free →Knowing the common failure patterns helps you configure monitoring that catches real problems and avoids false alerts.
A bad commit, missing env var, or dependency error fails the build, leaving your last good deploy live but blocking new changes. Monitoring the latest deploy state flags an error immediately so you fix it before the next planned release.
A deploy can succeed the build but still ship broken code or a 500-ing function. The deploy state shows ready while the live site is broken — which is why you also monitor the live URL with body validation, not just the API.
A revoked or rotated personal access token returns 401 on every API call, silently breaking automation. Monitoring the sites endpoint catches this so you can issue a new token.
A CI loop or repeatedly-hit deploy hook can exhaust the 3/min or 100/day deploy budget, blocking real deploys. Watching for 429s on deploy calls tells you it's a quota problem, not a platform outage.
Netlify Functions can be slow on cold start or hit execution timeouts under load. A dedicated function monitor with response-time thresholds and body validation catches degradation before users see failed requests.
In Netlify, go to User settings → Applications → Personal access tokens and create a new token. You'll send it as Authorization: Bearer YOUR_TOKEN. Note your site ID from Site settings → General.
Security tip: Create a dedicated token for monitoring so you can revoke it independently of your CI/CD tokens. The token has full account access, so store it securely.
Sign up at app.uptimesignal.io and add a new HTTP monitor:
Add a second, no-auth monitor on your live site URL with body validation.
Add a deploy-state monitor (/deploys?per_page=1, validate "ready") and a function health monitor if you use Functions. Together they separate build-time from runtime failures.
Route alerts where you'll act on them:
During deploy windows, use 1-minute checks (Pro plan) on your live site and deploy state so a bad release is caught within a minute instead of five — fast enough to roll back before most visitors notice.
Configure your monitors to alert on these conditions:
On your live site, validate for known page content so a blank or error page doesn't pass as a 200. On the deploy endpoint, check that the latest deploy's state is "ready", not "error". Body validation turns a generic 200 into a real "the deploy succeeded and the page actually renders" signal.
When monitoring alerts you to a Netlify problem, here's how to respond and limit the blast radius.
Check netlifystatus.com by component. Determine whether it's auth (401), rate limiting (429), a failed build, a bad deploy, a function error, or an edge incident. Each needs a different response.
If the live site broke right after a deploy, use Netlify's "publish deploy" / rollback to restore the previous good deploy instantly. This is usually the fastest fix — far quicker than debugging the broken build under pressure.
If the control-plane API is degraded, pause CI/CD steps that call it. Retrying deploys into an incident can burn your deploy rate limit and leave you locked out when things recover.
If only a function is failing while the static site is fine, the problem is your function code or its upstream dependency, not Netlify's edge. Check function logs and roll back the function deploy if needed.
Update your status page and notify your team. If it's an upstream Netlify incident, link the official status post so support tickets point to the right place.
curl -H "Authorization: Bearer YOUR_TOKEN" https://api.netlify.com/api/v1/sites. For continuous monitoring, set up UptimeSignal to poll the API and your live site every 1-5 minutes and alert you instantly when the status changes.
GET /api/v1/sites?per_page=1 as a lightweight auth + health check, add GET /api/v1/sites/{site_id}/deploys?per_page=1 to watch the latest deploy state, and monitor your live site URL for the CDN edge. If you use Netlify Functions, add a function endpoint and validate the body.
GET /api/v1/sites/{site_id}/deploys?per_page=1 and check the latest deploy's state — alert if it's error rather than ready. For functions, monitor a Functions URL (/.netlify/functions/your-function) and validate the body, since a function can return 200 with an error payload or fail on cold start.
UptimeSignal checks your endpoints from outside your network and catches errors before users do.
25 monitors free, unlimited for $10/month.
No password needed. We'll send a magic link.