Uptime monitoring for Vercel apps
Vercel's status page tells you if Vercel is up. SitePulse tells you if your app is up. External 1-minute checks on your production URLs, with email alerts when env vars, edge functions, or databases regress. Free for 5 monitors.
The bug Vercel can't see
You renamed an env var. The build succeeded. The deploy went out. Vercel's status page is green. Your users are getting 500s.
This is the most common indie-SaaS outage: a deploy that ships without a runtime crash for the first 30 seconds, then 500s the moment a real request touches the broken path. Vercel cannot detect it because Vercel doesn't know what your env vars should be.
SitePulse probes your URLs from outside the Vercel network. If anything 500s, returns the wrong status, or stops responding, you get an email within a minute.
What to monitor on a Vercel app
Production homepage
The single most important monitor. If your homepage is down, marketing, signup, and customer trust all break at once. Pair it with keyword matching on a phrase you'd never accidentally remove ('Get started' or your tagline).
/api/health endpoint
Build a public health check that does a real (but cheap) DB or upstream call. Monitor it. Catches env-var bugs, DB pool issues, and broken integrations before any customer hits them.
Customer-facing /api routes
Webhooks, checkout, search, login. A broken /api/checkout while the homepage works is the worst outage — silent, expensive, and only caught by direct probing.
Vercel Cron endpoints
Your /api/cron/* routes. If a daily-report cron starts 500ing, you'd never know unless you check logs. Point a monitor with the cron's auth header at it; alert before users notice the missing report.
Public status page (run by you)
Use SitePulse's public status page on your own slug. Embed it on your docs or marketing site. Builds trust, deflects 'is X down?' Slack pings.
External dependencies your app fronts
If your app proxies a third-party (Stripe, Supabase, OpenAI), monitor a route that exercises that dependency. The day OpenAI is degraded, your users will think it's your app — having the data to disprove it matters.
Set it up in 60 seconds
- Sign up with email or Google. No card.
- Add your production URL (the custom domain, not the *.vercel.app alias).
- Add /api/health and any /api routes customers depend on.
- Pick check interval (5-min on Free, 1-min on Pro at $9/mo).
- Optional: turn on keyword matching for content-level checks.
- Done. Email lands the moment anything goes red.
Bonus: monitor your Vercel Cron endpoints
If you have /api/cron/* routes, point a SitePulse monitor at them with the auth header Vercel uses. Now if a cron silently breaks, you find out before the absent daily report does.
Monitor URL: https://your-app.com/api/cron/check Method: GET Custom header: Authorization: Bearer <CRON_SECRET> Expected: 200, body contains "ok":true Interval: 5 min (or whatever matches your cron cadence)
What you get
1-minute checks
On Pro plan ($9/mo). Free plan checks every 5 minutes — enough for side projects.
Email alerts
Instant email when a monitor flips. Configurable failure threshold to suppress flakes.
Public status page
Free on every plan. Embeddable, indexed by Google. Communicate during incidents.
Add monitoring before your next deploy
5 monitors, 5-minute checks, email alerts, public status page — free forever. No credit card.
Frequently asked questions
Vercel has a status page — why do I need another monitor?+
Vercel's status page tells you if Vercel itself is operational. It cannot tell you if YOUR app is up. A successful deploy can ship broken code: a missing env var, a bad migration, an edge function that fails on cold start in a region. Vercel sees a healthy build; your users see 500s. SitePulse hits your URLs from outside Vercel — same as a real user — and emails you the moment they break.
What's the most common bug an external monitor catches that Vercel logs miss?+
Env-var typos. You renamed STRIPE_SECRET_KEY to STRIPE_KEY in code and forgot to update Vercel's env vars. Build succeeds. Deploy succeeds. Logs show no error — until /api/checkout 500s on the first real request 10 minutes later. SitePulse hits /api/health (or any other endpoint that exercises the affected code path) on every probe and emails you within 60 seconds. Same pattern catches Supabase RLS regressions, JWT signing issues, and webhook secrets with trailing whitespace.
How does this work with Preview deployments?+
Don't monitor Preview deployments — they get URL-of-the-month. Monitor production URLs (sitepulse.satosushi.co, app.yourdomain.com, the *.vercel.app aliased to your production deploy). Preview deploys self-destruct on next push, so SitePulse would just get 404s. For testing Preview deploys, use Vercel's built-in deployment checks or a manual smoke test.
Should I monitor my Vercel function regions?+
Indirectly. SitePulse runs from Tokyo (hnd1) and probes your URL — which routes to whichever Vercel function region serves your request. If your function is configured for a specific region (via vercel.json regions: ['hnd1']), the probe exercises that region's cold start, network, and runtime. Multi-region SitePulse probes are on the roadmap for explicit per-region testing.
Can I get a status page on a custom domain?+
Status pages live at sitepulse.satosushi.co/status/your-slug today, indexed by Google and shareable. Custom-domain status pages (status.yourdomain.com) are on the roadmap. The current URL is free on every plan, including Free.
What about Vercel Cron jobs — can I monitor those?+
Yes — point a SitePulse monitor at the cron's HTTP endpoint with the same Authorization header Vercel uses. Then if your cron route 500s on its next run, you find out from SitePulse, not from a user noticing a missing daily report. We do this for SitePulse's own daily-report cron.