How a Cursor app runs in production
An app built in Cursor lives in your own repository and deploys however you set it up — commonly to Vercel, Netlify, Cloudflare, Render, Fly.io or Railway, often straight from a push to GitHub.
Its backend is whatever you chose: Supabase or another Postgres, Stripe for payments, OpenAI or Anthropic for the AI features.
What breaks after launch
- Errors spike right after a publishCode that passed review and tests can still fail on production data the moment it ships.How to tell, and the fix
- An API key is in your public codeA key dropped into client code to make a feature work ends up in the bundle every visitor downloads.How to tell, and the fix
- AI usage is several times its usual levelA loop, a retry storm or a leaked key shows up first as usage — or, unwatched, on next month’s invoice.How to tell, and the fix
- It works in preview and breaks in productionA variable set on your machine or in preview and missing in production is still the most common way a good deploy fails.How to tell, and the fix
What Keelnest watches
The site, every five minutes
The address, its certificate and its security headers, requested the way a browser asks; an incident opens after two failures in a row, never on one blip.
Every deploy, on your host
With a read-only token each deploy is checked and walked by your journeys; on a host Keelnest does not connect to, a change to the live site counts as a publish.
What changed
With the Keelnest GitHub App on the repository, each publish shows the commits and files behind it, so an incident names the change that caused it.
Payments
A read-only Stripe key compares payments with what that hour of the week usually brings, and reads webhook endpoints and failed deliveries.
AI spend
OpenAI or Anthropic usage, read hourly, so a spike is caught within a few hours; paid plans add a daily budget that warns at 80% and alerts at 100%.
Errors
One script tag reports uncaught errors and failed requests — never form values or request bodies — so an incident says what broke. Sentry works too.
Fixes: a prompt, or a pull request
On a paid plan Keelnest prepares the fix as a pull request on your repository, checked on a preview where your host builds one, and merged only when a named person approves it. On every plan the incident carries a prompt you can hand to Cursor’s agent, with the evidence and the change to make.
Setting it up
- Add the production address. The first check runs straight away.
- Connect your host with a read-only token, and install the Keelnest GitHub App on the repository.
- Connect Stripe, and OpenAI or Anthropic, if the app takes payments or calls a model.
- Write one journey — sign in, or reach the checkout — in plain words. It is walked after every deploy.
Or start without an account: the free health check reads any live address in a few seconds.
Questions
Cursor already has agents that open pull requests. Why Keelnest?
They work on what you ask for, in the editor. Keelnest works on what broke in production — a failed deploy, payments that stopped, a key in the bundle — and says so with the evidence, before anybody asks.
Is it free?
Your first app is: the five-minute checks, the check after every publish, and one journey, walked weekly and after every publish. Paid plans add journeys, run them hourly or faster, and prepare fixes as pull requests.
Sources
What Cursor does, as its own documentation described it on 23 September 2026. Builders change quickly; if something here is out of date, tell us.