Perché il monitoraggio API è diverso#

Il tuo sito web può essere "up" mentre la tua API è rotta. Gli utenti vedono una homepage che si carica bene, ma la funzionalità dell'app da cui dipendono è completamente non funzionante.

Esempio: La tua pagina di checkout si carica (sito up), ma l'API di pagamento fallisce (sito rotto). I clienti non possono completare gli acquisti. I ricavi si fermano.

Il monitoraggio API rileva questi guasti invisibili.

Cosa richiede monitoraggio API#

Gateway di pagamento (Stripe, PayPal, Square)
Endpoint di autenticazione (login/logout)
API dati (cataloghi prodotti, dati utente)
Webhook (dati in arrivo da terze parti)
Endpoint di ricerca
API di upload media

Codici di stato HTTP nelle API#

Le API usano i codici di stato HTTP in modo diverso rispetto ai siti web:

Sito web:

200 OK: La pagina si carica
500 Server Error: Il sito è rotto

API:

200 OK: Richiesta riuscita
400 Bad Request: Il client ha inviato dati errati
401 Unauthorized: Autenticazione fallita
403 Forbidden: Permesso negato
404 Not Found: L'endpoint non esiste
429 Too Many Requests: Rate limited
500+ Server Error: Backend rotto

Differenza chiave: Un'API può restituire 200 OK con un errore nel body JSON.

Esempio:

{
  "status": 200,
  "success": false,
  "error": "Payment processing failed"
}

HTTP dice "OK", ma l'API è effettivamente fallita. Il monitoraggio uptime di base se lo perde.

Configurare il monitoraggio API#

Passo 1: Identifica gli endpoint API critici#

Elenca ogni endpoint API critico per il tuo business:

/api/auth/login (gli utenti non possono fare login se questo fallisce)
/api/payments/create (gli utenti non possono fare checkout)
/api/users/profile (l'app crasha se questo fallisce)
/webhooks/stripe (i pagamenti non vengono registrati se questo fallisce)

Passo 2: Determina la validazione delle risposte#

Per ogni endpoint, decidi cosa costituisce "up":

Check di base (stato HTTP):

L'endpoint restituisce 200 o 201 = OK

Check intermedio (Stato + Tempo di risposta):

L'endpoint restituisce 200 E risponde in < 1 secondo

Check avanzato (Stato + Contenuto del body):

L'endpoint restituisce 200 E il body della risposta contiene i dati attesi

Passo 3: Configura lo strumento di monitoraggio#

In Nova Uptime:

Aggiungi dominio: https://api.tuodominio.com
Per ogni endpoint critico, aggiungi come monitor separato:
- /api/auth/login
- /api/payments/create
- ecc.
Configura la validazione del body della risposta se disponibile
Imposta soglie di avviso (2 fallimenti consecutivi prima dell'avviso)

Avanzato: validazione del body della risposta#

Alcuni endpoint richiedono un formato di risposta specifico.

Esempio: endpoint di creazione pagamento

Risposta attesa:

{
  "success": true,
  "payment_id": "pay_12345",
  "amount": 99.99
}

Configurazione del monitoraggio:

Verifica se la risposta contiene "success": true
Se manca, l'endpoint è "rotto" anche se lo stato HTTP è 200

L'Email Health Checker di Nova Uptime valida i body delle risposte — lo stesso principio si applica al monitoraggio API.

Token di autenticazione nel monitoraggio API#

La maggior parte delle API richiede autenticazione. Per monitorarle:

Opzione 1: Crea una chiave API di test

Genera una chiave API dedicata di test per il monitoraggio
Usa questa chiave in tutte le richieste di monitoraggio
Questa chiave ha solo permessi di lettura (non può modificare i dati)
Usa questa chiave nello strumento di monitoraggio

Opzione 2: Endpoint pubblico

Alcune API hanno endpoint non autenticati (health check, status)
Monitora questi invece
Esempio: GET /api/health (pubblico, nessuna autenticazione richiesta)

Monitoraggio dei webhook#

I webhook sono più complessi. Sono in arrivo (li ricevi, non li mandi).

Monitora l'endpoint che riceve i webhook:

Esempio: Stripe invia POST a https://tuodominio.com/webhooks/stripe

Come monitorare:

Crea un mittente webhook di test (attivazione manuale)
Verifica che l'endpoint lo accetti e restituisca 200
Controlla i log che il webhook è stato processato

Oppure usa il monitoraggio sintetico:

Configura una richiesta POST sintetica all'endpoint webhook
Includi un payload di test
Verifica che venga ricevuto e processato

Monitoraggio dei tempi di risposta#

Le API non riguardano solo l'essere up/down. Riguardano anche la velocità.

API lenta = API rotta (dal punto di vista dell'utente).

Imposta soglie di tempo di risposta:

Endpoint di autenticazione: < 200ms
Endpoint di pagamento: < 500ms
Endpoint di ricerca: < 1000ms (più complesso)

Se un endpoint impiega 5 secondi a rispondere, anche se "funziona", gli utenti sperimentano timeout e se ne vanno.

Considerazioni sul rate limiting#

Le API spesso applicano rate limiting per prevenire abusi.

Problema: Il tuo monitoraggio invia un check ogni minuto. Con 1.000 monitor, sono 1.000 richieste al minuto. Se la tua API ha rate limit a 100/minuto, il monitoraggio viene bloccato.

Soluzione:

Crea una chiave API separata per il monitoraggio (con rate limit alto)
Oppure riduci la frequenza di check (controlla ogni 5 minuti invece di 1)
Oppure usa un endpoint interno /health che non ha rate limit

Errori comuni del monitoraggio API#

Errore 1: Monitorare la produzione con operazioni distruttive#

Non monitorare:

POST /api/users/delete    ← Cancella utenti a ogni check
POST /api/billing/charge  ← Addebita la carta a ogni check

Monitora invece operazioni di sola lettura:

GET /api/users/{id}
GET /api/health

Errore 2: Includere l'autenticazione nell'URL#

Non fare:

GET /api/endpoint?auth_token=SECRET

Questo mette i segreti nei log. Usa header invece:

Authorization: Bearer SECRET_TOKEN

Errore 3: Non testare gli endpoint webhook#

I webhook sono critici ma spesso non testati. Il tuo processore di webhook potrebbe essere completamente rotto, e non lo sapresti mai.

Soluzione: Invia regolarmente webhook di test e verifica che siano processati.

Monitorare le dipendenze API#

La tua API potrebbe dipendere da servizi esterni:

Database (se è down, l'API è down)
Coda di messaggi (Redis, RabbitMQ)
Cache (Memcached)
API esterne (Stripe, Twilio)

Monitorali separatamente:

Endpoint di health check del database
Endpoint di stato della cache
Pagina di stato delle API di terze parti

Impostare avvisi per i guasti API#

Quando il monitoraggio API rileva un guasto:

L'avviso dovrebbe includere:

Quale endpoint è fallito
Qual è stato il guasto (timeout vs errore 500)
Quando è iniziato
Modifiche recenti (se disponibili)

Severità degli avvisi:

Critical: API di pagamento/auth (utenti bloccati)
High: API di ricerca/dati (utenti frustrati)
Medium: Analytics/logging (errori visibili agli utenti)

Monitoraggio API in Nova Uptime#

Nova Uptime monitora l'uptime delle API insieme a quello dei siti web:

Aggiungi il tuo dominio API: https://api.tuodominio.com
Configura il monitoraggio degli endpoint
Ricevi avvisi via email/Slack
Visualizza la cronologia degli incidenti e i tempi di risposta
Screenshot automatici dei guasti (per il debug)

In più il monitoraggio email health — se la tua API invia email transazionali, Nova Uptime controlla automaticamente SPF/DKIM/DMARC sulla stessa dashboard.

Riepilogo#

Elenca gli endpoint API critici
Determina cosa significa "up" per ognuno (codice di stato, tempo di risposta, contenuto del body)
Crea il monitoraggio per ognuno
Imposta soglie di tempo di risposta
Monitora le dipendenze (database, cache, terze parti)
Testa i webhook regolarmente
Avvisa immediatamente sui guasti

Inizia a monitorare la tua API oggi: Monitoraggio API Nova Uptime. Include uptime + email health sulla stessa dashboard.

Monitoraggio uptime per API: monitorare endpoint e webhook