Come sai che la tua app è giù?

Cos'è e perché conta

Monitorare un'app vuol dire sapere che si è rotta prima che te lo dica qualcuno. Senza, se il sito va giù di notte lo scopri la mattina. E spesso non te lo scrive nessuno: chi trova l'app rotta la chiude e basta.

Per me il monitoraggio sono tre pezzi che lavorano insieme:

• Il controllo da fuori: un servizio che ogni pochi minuti apre il tuo indirizzo, come farebbe un utente, e guarda se risponde.
• Il registro degli errori: il posto dove finisce ogni errore dell'app, con lo stack trace, cioè la riga di codice dove si è rotto.
• L'avviso: la mail o la notifica sul telefono che ti arriva quando uno dei due trova qualcosa.

Il controllo deve stare fuori dalla tua app: se l'app è giù, non può dirtelo lei. Il registro degli errori invece ti dice cosa si rompe anche quando l'app risponde.

E se colleghi Claude Code al registro degli errori, quando scatta l'allarme non parti da zero.

1. Cosa uso

Uso due servizi. Non sono gli unici: con altri il procedimento è lo stesso.

Per gli errori: Sentry

Ogni errore dell'app arriva lì con lo stack trace, e da lì partono gli avvisi. Il piano gratuito si chiama Developer: è per un utente solo e manda gli avvisi via email.

Per il controllo ogni 5 minuti: UptimeRobot

Apre il tuo indirizzo e, se non risponde, ti avvisa via email e con una notifica sull'app del telefono. Piano gratuito: 50 monitor, controllo ogni 5 minuti; le condizioni d'uso controllale sul loro sito.

2. La mezz'ora

Si fa una volta sola, in circa mezz'ora se l'app è già online.

Sentry nell'app

1. Crea un progetto su Sentry. Ti mostra il DSN, la chiave del progetto: è l'indirizzo a cui la tua app manda gli errori. Lo ritrovi nelle impostazioni del progetto, alla voce Client Keys (DSN).
2. Copialo e scrivi a Claude Code:

Aggiungi Sentry a questa app usando il DSN che ti do, in una variabile d'ambiente e non nel codice. Poi fai partire un errore di prova e dimmi come verifico che è arrivato.

L'errore di prova è la parte che conta: finché non lo vedi arrivare su Sentry, non sai se funziona. Poi controlla negli avvisi di Sentry che ci sia una regola per gli errori nuovi.

Una pagina da controllare

La home a volte si carica anche con il database fermo. Per questo al controllo do una pagina apposta:

Crea una pagina /health che risponde ok solo se l'app e il database funzionano.

Quando qualcosa non va, la pagina deve rispondere con un codice di errore. Se mostra una pagina normale con scritto «errore», il controllo la vede aprirsi e pensa che vada tutto bene. Se Claude non l'ha già fatto, aggiungo:

Se qualcosa non funziona, /health deve rispondere con un codice di errore, tipo 503, e non deve mostrare dettagli interni come password, indirizzi del database o messaggi di errore completi.

Il controllo ogni 5 minuti

1. Su UptimeRobot crea un nuovo monitor su [indirizzo della tua app]/health, con un controllo ogni 5 minuti.
2. Come avvisi attiva l'email e l'app sul telefono, dove fai l'accesso con lo stesso account.
3. Per provarlo, metti per un attimo nel monitor un indirizzo sbagliato e guarda se ti arriva l'avviso. Poi rimetti quello giusto.

Sentry dentro Claude Code

Ultimo passo: colleghi Sentry a Claude Code con un server MCP, così Claude può leggere i tuoi errori. Nel terminale lancia questa riga, con i nomi brevi della tua organizzazione e del tuo progetto su Sentry al posto di TUA-ORG e TUO-PROGETTO:

claude mcp add --transport http sentry https://mcp.sentry.dev/mcp/TUA-ORG/TUO-PROGETTO

Al primo uso ti fa accedere a Sentry dal browser; se non succede, scrivi /mcp in Claude Code e scegli sentry. Il collegamento vale solo nel progetto in cui hai lanciato la riga.

3. Quando scatta l'allarme

Quando arriva la mail o la notifica, apro Claude Code nel progetto e incollo l'allarme in questo prompt:

Mi è arrivato questo allarme: [incolla]. Leggi l'errore su Sentry e i log, e scrivimi in cinque righe: cosa si è rotto, da quando, perché, e la correzione che proponi. Non toccare niente in produzione finché non ti dico ok.

Cinque righe perché in quel momento mi serve capire, non leggere. «Da quando» mi dice se c'entra l'ultimo deploy. E l'ultima frase è la più importante: con l'app giù viene voglia di correggere al volo, e una correzione sbagliata in produzione può fare più danni dell'errore.

4. Se lo vuoi automatico

Il passo dopo è non dover nemmeno incollare l'allarme. Le strade sono due.

Con una sessione aperta: /loop

Il modo semplice: lasci aperta una sessione di Claude Code, con Sentry già collegato, e scrivi:

/loop 5m controlla su Sentry se ci sono errori nuovi; se sì, leggi lo stack trace e scrivimi cosa si è rotto e come lo sistemeresti.

Ogni 5 minuti Claude guarda Sentry e ti scrive solo se trova errori nuovi: sono circa 288 giri al giorno, quindi tieni il prompt corto. Funziona solo a sessione aperta e computer acceso, e dopo 7 giorni il loop si cancella da solo.

A computer spento: una routine con trigger API

Una routine nel cloud gira anche a computer spento, ma a orario parte al massimo una volta all'ora. Per un allarme conviene il trigger API: un indirizzo web che avvia la routine quando lo chiami con il token giusto.

Due cose da sapere prima: le routine richiedono un piano Claude a pagamento e sono ancora in anteprima, quindi come funzionano può cambiare.

1. Su claude.ai/code/routines clicca New routine. Il progetto deve stare su GitHub.
2. Aggiungi Sentry come connettore su claude.ai/customize/connectors: il collegamento fatto con claude mcp add vive sul tuo computer e la routine non lo vede. Togli i connettori che non servono: durante la routine Claude li usa senza chiedere.
3. Come trigger scegli API e salva. Si aggiunge dal sito, non con /schedule.
4. Copia l'indirizzo della routine, clicca Generate token e copia subito il token: lo vedi una volta sola.
5. Nel tuo strumento di avvisi imposta una chiamata a quell'indirizzo con il token, con il testo dell'allarme nel campo text.

Il limite: il trigger API vuole il token e degli header precisi, che trovi nell'esempio accanto all'indirizzo. Gli strumenti di avvisi gratuiti potrebbero non riuscire a chiamarlo, quindi controlla prima nel tuo.

Il testo dell'allarme arriva alla routine come dato da leggere, non come ordine: nel prompt devi dirle tu di indagare. Io uso questo:

Indaga sull'allarme descritto nel blocco routine-fire-payload. Leggi l'errore su Sentry, guarda i commit recenti e scrivimi in cinque righe: cosa si è rotto, da quando, perché, e la correzione che proponi. Non toccare niente in produzione.

La routine gira senza chiederti permessi, e il risultato lo trovi nella sessione che crea a ogni partenza. Per questo «Non toccare niente in produzione» resta: lei indaga e propone, tu decidi.

Gli errori più comuni

• Controllare solo la home: può caricarsi anche con il database fermo, quindi fai controllare /health.
• Una /health che risponde con una pagina normale anche quando c'è un errore: falle restituire un codice di errore.
• Non provare niente: fai partire l'errore di prova e un avviso finto, e guarda se ti arrivano.
• Lasciare che Claude corregga in produzione durante l'allarme: chiedi prima la diagnosi e la proposta, poi decidi tu.
• Dare per scontato che la routine veda il Sentry collegato nel terminale: aggiungilo come connettore su claude.ai.

Checklist

• Sentry nell'app, con il DSN in una variabile d'ambiente
• Errore di prova arrivato su Sentry
• Pagina /health che controlla app e database
• Monitor ogni 5 minuti su /health, avvisi su email e telefono
• Sentry collegato a Claude Code, accesso fatto
• Prompt dell'allarme salvato dove lo ritrovi subito

Domande frequenti