The deploy that passed and did not work
The build is green, the agent said it was done, and the page returns a 500 because an environment variable was renamed. You find out from a user.
Monitoring for Cursor apps
Your Cursor app is live. Who tells you when it isn't?
Cursor writes the code fast enough that you ship more than you used to. Every one of those deploys is a chance to break something nobody is watching, on a server nobody is looking at.
Where it runs: you deploy what Cursor wrote yourself: Vercel, Netlify, Railway, Fly, a VPS.
Paste your app's address. We propose the checks, you say yes:
We read the page once and propose the checks it needs. Nothing is created until you say so.
Or just check it once, no account:
What breaks after launch
None of these show up in the editor. All of them show up to your users first.
The certificate on the VPS
Vercel renews certificates for you; a droplet does not. Certbot's cron stops after an OS upgrade, and ninety days later the site shows a browser warning.
The domain you forgot you bought
The domain was registered in the first hour of the project and never thought about again. A year later it lapses, and the site, the mail and the API go with it.
Third-party APIs the agent wired in
Cursor added the OpenAI call, the Stripe webhook and the Resend send in an afternoon. Each is an outside service with a key, a quota and an uptime of its own.
The background job nobody sees
A queue worker that crashed on Tuesday and nobody restarted. The site loads; the emails and reports stop.
The email problem
An app written with Cursor sends mail the way the agent set it up: a call to Resend or Postmark or SES from a route or a job, with a key in an environment variable and a sending domain configured once. Deploys are where it breaks: the variable is missing on the new host, the job worker is not started, a dependency update changes the client's API. The route still answers 200, because the send is awaited or not, and the failure is a log line on a server nobody tails. ServerInspector watches from outside: the site, the API routes, the domain and its certificate. On Pro, an API test can call the endpoint that sends (with a test flag) on a schedule and assert on the response, and the deploy integration silences alerts for ten minutes while you ship and then tells you if the site did not come back.
How to set it up
Nothing is installed in the app. Monitoring happens from outside, the way your users reach it.
- 1
Type your app's address into the free check above. It tells you in twenty seconds whether the site answers, how fast, whether the certificate and domain are in order, and which security headers are missing.
- 2
Create a free account and add the same address as a monitor. It is checked every five minutes (every minute on Pro), and you get an email when it stops answering and another when it is back.
- 3
Add your custom domain under Domains. Expiry is tracked and you are reminded 30, 14, 7 and 1 day before renewal.
- 4
Add your API's health endpoint as a monitor. If you do not have one, ask Cursor for `GET /health` that checks the database and the queue and returns 200 only when both answer.
- 5
Issue a deploy token under Settings and call `/deployments/deploy` from your CI: alerts are held for ten minutes while the new version starts, and you are told if it does not.
Free plan: 10 monitors or domains, 5-minute checks, commercial use welcome, no card.