Vercel auto-scales and rolls back gracefully, which makes it a forgiving host. The monitoring questions are different from a self-managed VPS: you're not watching for the server to die, you're watching for deployment-related regressions, edge config issues, and slow function cold-starts.
Always monitor the apex (e.g. https://example.com) as the canonical health check — it should always 200 and render the homepage. Set up your monitor to follow redirects so a misconfigured naked-to-www redirect doesn't fire as a false positive.
If you have a public API or critical webhook handler (Stripe, GitHub, Polar) running as a Vercel Function, monitor that route directly. Cold starts can spike response time after long idle periods — watch the trend.
Monitor /login or /api/auth/session — a misconfigured auth provider often returns 200 on the homepage but breaks sign-in. We've seen this happen after a Better Auth or NextAuth env var rotation.
Don't add your *.vercel.app preview URLs as monitors — they get torn down with every PR and will generate constant false alerts. Stick to the production domain.
If you use edge runtime functions, our European checks measure latency from Europe. A function that's fast for US users but slow for European users will look 'degraded' to us.
Some Vercel projects with aggressive bot protection (Cloudflare in front, etc.) will start blocking our user-agent if we hit them every 5 minutes from the same IP. Whitelist our user-agent string if you see this.