How do you know your app is down?

What it is and why it matters

Monitoring an app means knowing it broke before someone tells you. Without it, if the site goes down at night you find out in the morning. And often nobody writes to tell you: whoever finds the app broken just closes it.

For me, monitoring is three pieces working together:

• The outside check: a service that opens your address every few minutes, the way a user would, and sees whether it responds.
• The error log: the place where every error in the app ends up, with the stack trace, meaning the line of code where it broke.
• The alert: the email or the phone notification you get when one of the two finds something.

The check has to live outside your app: if the app is down, it can't tell you itself. The error log, on the other hand, tells you what breaks even when the app responds.

And if you connect Claude Code to the error log, you don't start from scratch when the alert goes off.

1. What I use

I use two services. They aren't the only ones: with others the process is the same.

For errors: Sentry

Every error in the app lands there with its stack trace, and that's where the alerts come from. The free plan is called Developer: it's for a single user and sends alerts by email.

For the 5-minute check: UptimeRobot

It opens your address and, if it doesn't respond, alerts you by email and with a notification in the phone app. Free plan: 50 monitors, a check every 5 minutes; check the terms of use on their website.

2. The half hour

You do it only once, in about half an hour if the app is already online.

Sentry in the app

1. Create a project on Sentry. It shows you the DSN, the project key: it's the address your app sends its errors to. You'll find it again in the project settings, under Client Keys (DSN).
2. Copy it and write to Claude Code:

Add Sentry to this app using the DSN I give you, in an environment variable and not in the code. Then trigger a test error and tell me how I check that it arrived.

The test error is the part that matters: until you see it arrive on Sentry, you don't know whether it works. Then check in Sentry's alerts that there's a rule for new errors.

A page to check

The home page sometimes loads even with the database down. That's why I give the check a dedicated page:

Create a /health page that responds ok only if the app and the database are working.

When something is wrong, the page has to respond with an error code. If it shows a normal page that says “error”, the check sees it open and thinks everything is fine. If Claude hasn't already done it, I add:

If something isn't working, /health has to respond with an error code, like 503, and it must not show internal details such as passwords, database addresses or full error messages.

The check every 5 minutes

1. On UptimeRobot, create a new monitor on [your app's address]/health, with a check every 5 minutes.
2. For alerts, turn on email and the phone app, where you sign in with the same account.
3. To test it, put a wrong address in the monitor for a moment and see whether the alert reaches you. Then put the right one back.

Sentry inside Claude Code

Last step: you connect Sentry to Claude Code with an MCP server, so Claude can read your errors. In the terminal, run this line, with the short names of your organization and your project on Sentry in place of YOUR-ORG and YOUR-PROJECT:

claude mcp add --transport http sentry https://mcp.sentry.dev/mcp/YOUR-ORG/YOUR-PROJECT

The first time you use it, it has you sign in to Sentry from the browser; if that doesn't happen, type /mcp in Claude Code and choose sentry. The connection only works in the project where you ran the line.

3. When the alert goes off

When the email or the notification comes in, I open Claude Code in the project and paste the alert into this prompt:

I got this alert: [paste]. Read the error on Sentry and the logs, and write me five lines: what broke, since when, why, and the fix you suggest. Don't touch anything in production until I say ok.

Five lines because in that moment I need to understand, not to read. “Since when” tells me whether the last deploy has anything to do with it. And the last sentence is the most important: with the app down you want to fix it on the spot, and a wrong fix in production can do more damage than the error.

4. If you want it automatic

The next step is not even having to paste the alert. There are two ways.

With a session open: /loop

The simple way: you leave a Claude Code session open, with Sentry already connected, and type:

/loop 5m check Sentry for new errors; if there are any, read the stack trace and tell me what broke and how you would fix it.

Every 5 minutes Claude looks at Sentry and writes to you only if it finds new errors: that's about 288 rounds a day, so keep the prompt short. It only works with the session open and the computer on, and after 7 days the loop deletes itself.

With the computer off: a routine with an API trigger

A cloud routine runs even with the computer off, but on a schedule it starts at most once an hour. For an alert, the API trigger is the better fit: a web address that starts the routine when you call it with the right token.

Two things to know first: routines require a paid Claude plan and are still in preview, so the way they work can change.

1. On claude.ai/code/routines, click New routine. The project has to be on GitHub.
2. Add Sentry as a connector at claude.ai/customize/connectors: the connection you made with claude mcp add lives on your computer and the routine can't see it. Remove the connectors you don't need: during the routine Claude uses them without asking.
3. For the trigger, choose API and save. It's added from the website, not with /schedule.
4. Copy the routine's address, click Generate token and copy the token right away: you only see it once.
5. In your alerting tool, set up a call to that address with the token, with the text of the alert in the text field.

The limit: the API trigger needs the token and specific headers, which you'll find in the example next to the address. Free alerting tools might not be able to call it, so check yours first.

The text of the alert reaches the routine as data to read, not as an order: in the prompt you have to tell it to investigate. I use this one:

Investigate the alert described in the routine-fire-payload block. Read the error on Sentry, look at the recent commits and write me five lines: what broke, since when, why, and the fix you suggest. Don't touch anything in production.

The routine runs without asking you for permissions, and you'll find the result in the session it creates each time it starts. That's why “Don't touch anything in production” stays: it investigates and suggests, you decide.

Common mistakes

• Checking only the home page: it can load even with the database down, so have /health checked instead.
• A /health that responds with a normal page even when there's an error: have it return an error code.
• Not testing anything: trigger the test error and a fake alert, and see whether they reach you.
• Letting Claude fix things in production during the alert: ask for the diagnosis and the proposal first, then you decide.
• Assuming the routine can see the Sentry you connected in the terminal: add it as a connector on claude.ai.

Checklist

• Sentry in the app, with the DSN in an environment variable
• Test error showed up on Sentry
• /health page that checks the app and the database
• Monitor on /health every 5 minutes, alerts by email and on the phone
• Sentry connected to Claude Code, signed in
• Alert prompt saved where you can find it right away

Frequently asked questions