Monitoring for Claude Code apps

    Your Claude Code app is live. Who tells you when it isn't?

    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:

    No account needed. One check, from Frankfurt, in about twenty seconds.

    What breaks after launch

    None of these show up in the editor. All of them show up to your users first.

    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.

    Deploys that ship migrations

    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.

    The certificate and the domain

    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.

    The APIs the code depends on

    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.

    Scheduled work

    Solid Queue, Sidekiq, cron: the report that did not send and the cleanup that did not run are invisible from the home page.

    The email problem

    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.

    How to set it up

    Nothing is installed in the app. Monitoring happens from outside, the way your users reach it.

    1. 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. 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. 3

      Add your custom domain under Domains. Expiry is tracked and you are reminded 30, 14, 7 and 1 day before renewal.

    4. 4

      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.

    5. 5

      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.

    Questions Claude Code builders ask