Infrastructure that was set up once
The agent configured nginx, the certificate renewal, the systemd unit and the cron job in a session you have since closed. Any of them can stop and nothing in the repository will show it.
Monitoring for Claude Code apps
Claude Code will set up the server, write the deploy and ship the feature in one session. It will not be there at three in the morning when the certificate expires. Something else has to be.
Where it runs: you deploy what Claude Code built: a VPS with Kamal or Docker, Fly, Railway, Vercel.
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:
None of these show up in the editor. All of them show up to your users first.
The agent configured nginx, the certificate renewal, the systemd unit and the cron job in a session you have since closed. Any of them can stop and nothing in the repository will show it.
A migration that locks a table for a minute, a job worker that did not restart, an environment variable that changed name: the site is down for the length of time it takes someone to notice.
Automated renewal is automated until it is not. The domain renews on a card that expires. Both fail on a schedule you are not looking at.
Anthropic, OpenAI, Stripe, Resend: each has its own outages, rate limits and key rotations, and each one the app calls is a way for the app to break without a line of your code changing.
Solid Queue, Sidekiq, cron: the report that did not send and the cleanup that did not run are invisible from the home page.
Apps built with Claude Code send mail through a provider the agent wired in, usually with a delivery method and a job. The failure modes are the same as any transactional mail, and the agent is not around to notice them: the provider's key revoked or rotated, the sending domain's DNS changed, the job queue stopped, a 5xx from the provider that the job dropped rather than retried. ServerInspector was built exactly this way, and it monitors itself with the same tools: the site and API as monitors, the domain and certificate tracked, an API test that exercises the sending endpoint on a schedule, deploy markers from the pipeline, and a public health endpoint that says whether the worker is alive. The same setup is a few minutes for any app the agent built.
Nothing is installed in the app. Monitoring happens from outside, the way your users reach it.
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.
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.
Add your custom domain under Domains. Expiry is tracked and you are reminded 30, 14, 7 and 1 day before renewal.
Ask Claude Code for a health endpoint that returns 503 when the job worker has not run in a few minutes; add it as a monitor. That is how you learn the queue died.
Add a deploy marker call to your deploy script (`kamal deploy && curl -X POST …/deployments/deploy`), so a restart is not an alert and a failed deploy is.
Free plan: 10 monitors or domains, 5-minute checks, commercial use welcome, no card.