Vercel uptime monitoring: outside-in Vercel monitoring and downtime alerts for Next.js apps

Short answer: Vercel does not ship an uptime monitor. Vercel Observability is real and useful, but every signal in it is derived from a request that already reached Vercel: function invocations, edge requests, middleware, external API calls, image optimization, ISR. If the request never arrives, no event is created, so there is nothing to alert on. Broken DNS, a lapsed domain, a failed certificate renewal on a custom domain and a Vercel platform incident all produce the same reading in your dashboard as a quiet Tuesday. You need a check that runs from outside Vercel.

Check a URL first ▸

Last updated September 2026 · Vercel capabilities checked against vercel.com/docs/observability

alertping ▸ run check

live

▸ type a domain and run a real-feel check

▸ probes from 3 regions · FRA · IAD · SIN

▸ waiting…▌

If ever goes down, you get:

Alert fired ▸ 2 channels · 6.2 s after first failure

AlertPing app

● DOWN : HTTP timeout confirmed from 3/3 regions (FRA, IAD, SIN). Incident opened.

sms · on-call

AlertPing: DOWN. Confirmed 3/3 regions . First fail: Frankfurt.

read this first

Everything Vercel measures starts with a request that arrived

This is not a criticism of Vercel Observability. It is a description of what kind of tool it is. Vercel documents the event types it tracks, and the list is consistent: edge requests, Vercel Function invocations, external API requests, routing middleware invocations and AI Gateway requests. Vercel creates one or more of those events each time a request is made to your site.

Read that sentence as an availability engineer rather than a performance engineer and the consequence is immediate. The measurement begins at the moment traffic lands on Vercel's edge. Everything that can go wrong before that point is invisible, and a large share of real outages happen before that point. Vercel is telling you how the requests that reached you behaved. It cannot tell you about the requests that never got there, because from its position those requests do not exist.

The failure signature is the part that catches teams out. An inbound-only tool does not go red during this class of outage. It goes quiet. Zero errors, zero slow routes, zero anomalies in the function view. Silence and health look identical on a dashboard built from arriving traffic, which is why these incidents are usually reported by a customer rather than by a monitor.

The mechanism

No request, no event

Vercel creates observability events per request. A DNS failure, an expired domain or a broken custom-domain certificate stops the request before it becomes an event. There is no error to count because there was no request to count it against.

The signature

Outages look like quiet

A total front-door failure produces a flat zero line, not a spike. Error-rate alerting is built to notice bad requests, so it stays silent when the failure mode is the complete absence of requests.

The dependency

The monitor shares the fate

When Vercel itself has an incident, the tool reporting on your app is inside the thing that is degraded. A monitor that runs on independent infrastructure is the only one that can page you during a platform-level event.

the honest table

What Vercel detects, and what only an external check detects

Eleven ways a production Vercel deployment stops serving customers correctly, and where each one shows up. Vercel wins several of these outright and we have said so.

Failure	Vercel Observability	External uptime check
A Vercel Function returns 500 on one route	Detects it well	Only if that route is checked
One route's latency degrades badly	Detects it well	Detects it if checked, with less detail
An external API your function calls slows down	Detects it well	Only as knock-on latency
Error rate spikes across many routes	Detects it well	Detects it
DNS record deleted or pointed at the wrong target	No, request never arrives	Detects it
Domain registration lapses	No, request never arrives	Detects it
Custom-domain certificate fails to renew	No, handshake fails first	Detects it, and warns before expiry
Vercel platform or regional incident	No, the tool is inside the incident	Detects it
Production alias removed or reassigned	No, traffic stops arriving	Detects it
Deployment protection left enabled on production	Sees the requests, does not flag them	Detects it as an unexpected status
A backing database or API is down but pages still render	Partly, if the function errors	Detects it with a keyword or status assertion

Four of the eleven belong to Vercel and it is not close. If your problem is that a specific route is slow or throwing, Observability with traces and per-route breakdowns will find the cause faster than any external checker, because it can see inside the request. The seven shaded rows are the ones that are structurally out of reach, and they are disproportionately the ones that take an entire site down rather than degrading one endpoint.

the obvious objection

Will Vercel's anomaly alerts catch traffic dropping to zero?

Sometimes, and it is a fair objection, so here is the honest answer. Vercel does offer anomaly alert configuration on Observability, and an anomaly detector watching request volume can in principle fire when traffic collapses. On a high-traffic production app with a stable daily curve, that is a genuine second line of defense and worth turning on.

It is a weak primary signal for three reasons, all of them statistical rather than ideological. An anomaly detector needs a baseline, so it needs enough traffic for zero to be distinguishable from a quiet hour. Most apps do not have that at 03:00, at weekends, or in their first year. It needs time to establish that the drop is real, which turns a detection that should take 30 seconds into one that takes many minutes. And it is inferential rather than direct: it concludes something might be wrong because a number moved, instead of reporting that a request to your URL failed. Those are different claims, and only one of them can be put in front of a customer or used to evidence an availability target.

There is also the shared-fate problem that no configuration solves. An alert pipeline running inside the platform experiencing the incident is not an independent witness. For the same reason we tell people not to host their status page on the infrastructure it reports on, the thing that watches the front door should not live behind it.

the mechanics

Setting up external uptime monitoring for a Vercel app

Four steps, and none of them touch your deployment. Nothing gets installed in your project, there is no SDK, no middleware and no build change.

Monitor the apex, not the vercel.app URL

Check the custom domain your customers actually type. The project's preview subdomain skips your DNS and your certificate, which are two of the failure modes you are trying to cover.

Add a health route with a real dependency

A route that touches your database and returns a known string turns a check from "the edge answered" into "the app worked". Assert on that string, not just on the status code.

Confirm from more than one region

A single vantage point cannot separate a dead app from a bad route to it. Every failure here is re-tested from three regions before it counts as downtime, which is what keeps the pager honest.

Route the alert to a human

Email, SMS, Slack and webhooks are on every plan, with escalation if the first person does not acknowledge. An alert that lands only in a channel nobody reads at 03:00 is not a monitor.

pick one

Which Vercel teams actually need this

Agencies shipping client sites

The highest-risk case, because the domains usually sit in the client's registrar account and expire without warning to you. Vercel cannot see a lapsed registration on a domain that is not in your control. An external check on each client apex is the only thing standing between a silent expiry and an angry phone call.

SaaS with a contractual uptime target

You cannot evidence an availability number using the platform's own inbound telemetry, for the same reason you would not accept a supplier's self-reported figures. Independent checks at a known interval produce a record you can put in front of a customer during a credit claim.

Small teams without a night shift

Low overnight traffic is exactly the condition under which anomaly detection on request volume performs worst, because there is no baseline to deviate from. A direct check does not care how much traffic you have. It either got a good response or it did not.

straight answer

What we do not do, and when to keep using Vercel's tools

We check from outside and we tell you fast. We do not do the things that require sitting inside your request path, and you should not replace Vercel Observability with this.

No request traces. We cannot show you the path of a single request through your middleware and functions. Observability can, and that is the right tool for debugging a slow route.
No per-route cost or usage attribution. Bandwidth, function invocation counts and image optimization spend are Vercel's data and stay in Vercel.
No log search. We report that a check failed and what came back. Finding the stack trace behind it happens in your logs.
No scripted browser journeys. We check endpoints, status codes, response content, SSL expiry and ports. We do not drive a headless browser through a multi-step checkout.
No free plan. Flat pricing from $19 a month for 20 monitors, with 30-second checks from $59. If you need one check on one hobby project, there are free tools and we are not the cheapest answer.

questions people ask

Vercel uptime monitoring questions

Does Vercel have uptime monitoring?

No. Vercel ships Observability with logs, traces, metrics and anomaly alerts, available on all plans with an Observability Plus upgrade for paid Pro and Enterprise teams. All of it is built from requests that reached Vercel. There is no outside-in check that visits your production URL on a schedule and alerts when the visit fails.

Does Vercel alert you when your site goes down?

It alerts on anomalies in traffic and spikes in server errors, so it will usually catch a deploy that starts throwing 500s. It will not reliably alert on a total front-door failure, because that produces no requests and therefore no errors. Broken DNS, an expired domain and a failed certificate renewal all fall into that gap.

How do I monitor a Vercel app for downtime?

Point an external monitor at your custom domain rather than the vercel.app URL, add a health route that touches a real dependency, assert on a known response string instead of only the status code, confirm failures from several regions before paging, and send the alert somewhere a person will see it at night. No code changes to your project are needed.

What is the difference between Vercel Observability and uptime monitoring?

Observability explains behavior from the inside using data your traffic generated. Uptime monitoring establishes from the outside whether the service is reachable and correct at all. One answers why a request was slow, the other answers whether a request was possible. Teams that run both use Observability for root cause and an external checker to detect and page.

Does Vercel monitor SSL certificate expiry on custom domains?

Vercel provisions and renews certificates for custom domains automatically, and renewal normally just works. What is missing is the independent warning when it does not, usually because a DNS record changed and validation can no longer complete. An external check reads the live certificate on every run and warns days ahead of expiry.

Can I monitor a Vercel serverless function endpoint?

Yes. A function route is just an HTTPS endpoint, so it can be checked like any other API: expected status code, expected response body, response time threshold, and custom headers if the route needs authentication. Checking a function that reaches your database is the single most useful check on a Vercel project.

How will I know if Vercel itself is down?

Not from inside Vercel. During a platform incident the telemetry pipeline is part of the affected system, and Vercel's own status page tells you about Vercel rather than about your specific deployment. A monitor running on unrelated infrastructure is the only thing that can tell you your app is unreachable while the platform is degraded.

Do I need uptime monitoring if I am on Vercel Enterprise?

The plan changes your support, limits and retention. It does not change where the measurement starts. Every tier of Observability derives from arriving requests, so the seven failure modes in the table above are out of reach on Enterprise for the same structural reason they are on Hobby.

Watch your Vercel app from outside Vercel

AlertPing checks your custom domains, API routes and serverless function endpoints as often as every 30 seconds, confirms every failure from three regions before it counts as downtime, warns before your SSL certificate expires, and sends SMS, email, Slack and webhook alerts on every plan with no credit packs. Flat pricing from $19 a month, with 30-second checks from $59.

See pricing

keep reading