What you are setting up
Two checks (production, and optionally one preview deployment you are actively debugging), the Errors SDK, and a status page. No agent step: Vercel functions are ephemeral and give you no persistent server to run one on, and that is expected, not a gap in coverage.
Create the checks
Point a check at your production domain, and, if you want it, a second at a specific preview URL while you are actively working a branch. A permanent check on every preview deployment is usually the wrong call: preview URLs are created and torn down constantly, and a check left pointed at a deleted one will alert on nothing meaningful.
export REALUPTIME_API_KEY=ru_live_...
realuptime checks create \
--name "Production" \
--url https://myapp.example.com/ \
--interval 60 \
--regions iad,sjc,fra,nrt
# Optional: a specific preview deployment, while you are debugging one
realuptime checks create \
--name "Preview: staging branch" \
--url https://myapp-git-staging-acme.vercel.app/ \
--interval 300 \
--regions iadVercel's serverless functions can cold-start; a 60-second interval and a generous timeout (see Checks & monitors) avoid mistaking a cold start for downtime.
Connect RealUptime Errors
If the project is Next.js on Vercel, follow Monitor a Next.js app for the exact instrumentation.ts wiring; it works unchanged on Vercel's Node runtime. Set the DSN as a Vercel environment variable rather than committing it:
# Vercel dashboard -> Project -> Settings -> Environment Variables
REALUPTIME_ERRORS_DSN=https://...@ingest.realuptime.io/...Vercel's Edge runtime (middleware, and any route explicitly set to runtime: "edge") is not supported by the adapter: it is a stripped-down JavaScript environment with no Node APIs, and the SDK's transport needs Node's network stack. Exceptions thrown there are not captured today.
Add a status page
Create a status page from the dashboard and add the production check as a component. See Status pages for custom domains (a status page on your own subdomain, separate from Vercel's) and subscriber notifications.
What RealUptime does and does not see
The check sees the HTTP response your deployment returns, from each region you chose, exactly like any other visitor. It does not see Vercel's build logs, deployment status, function cold-start counts, or bandwidth usage; for that, Vercel's own dashboard and its status page (vercel-status.com) are the source of truth, and RealUptime does not duplicate it.
There is no Monitor agent for a Vercel project, and there will not be one: the agent needs a long-lived process with access to /proc or an OS-level API, and a Vercel function is neither. If part of your stack runs on a VPS you do control (a worker, a database, a queue), see Monitor a Hetzner VPS or Monitor Docker containers for that half.