Monitoring uptime: UptimeRobot vs self-hosted

Monitoring uptime: UptimeRobot vs self-hosted

Il monitoraggio uptime e il livello base di controllo per qualsiasi servizio web. Sapere immediatamente quando un sito o un'API smette di rispondere e fondamentale. Le opzioni si dividono tra SaaS come UptimeRobot e soluzioni self-hosted come Uptime Kuma. Vediamo le differenze.

UptimeRobot: SaaS pronto all'uso

UptimeRobot e uno dei servizi più popolari: gratuito fino a 50 monitor con check ogni 5 minuti, piani a pagamento per check più frequenti e funzionalita avanzate (SSL monitor, port check, keyword, pause maintenance). Vantaggi: zero gestione, geo-distribuzione dei nodi di check, alerting via email/SMS/webhook/integrazioni.

Uptime Kuma: self-hosted moderno

Uptime Kuma e l'alternativa open source dominante: interfaccia simile a UptimeRobot, supporto a HTTP/HTTPS, TCP, ping, DNS, push monitor, status page pubblica. Si installa via Docker in minuti. Vantaggi: controllo totale, nessun limite sui monitor, privacy, dati sotto il tuo dominio.

Confronto sintetico

  • Setup: UptimeRobot immediato; Uptime Kuma 15 minuti di setup.
  • Costo: UptimeRobot gratuito fino a soglia, poi a pagamento; Kuma gratis ma server hosting incluso.
  • Geo distribuito: UptimeRobot ha nodi globali; Kuma e dove lo metti.
  • Affidabilità: UptimeRobot indipendente da tua infrastruttura; Kuma deve essere ospitato esterno per essere utile.
  • Privacy: Kuma vince, dati sotto tuo controllo.
  • Integrazioni: entrambi supportano webhook, Slack, Telegram, Discord, email, SMS.

Procedura passo-passo per Uptime Kuma

  1. Predisponi un piccolo VPS (1 CPU, 1 GB RAM) fuori dalla tua infrastruttura.
  2. Installa Docker e Docker Compose.
  3. Avvia Uptime Kuma con docker run -d --restart=always -p 3001:3001 -v uptime-kuma:/app/data --name uptime-kuma louislam/uptime-kuma.
  4. Configura reverse proxy con HTTPS via Caddy o Nginx.
  5. Crea account admin e abilita 2FA.
  6. Aggiungi i monitor: HTTP, ping, keyword, DNS, push.
  7. Configura notifiche multiple (Telegram per urgenze, email per riepiloghi).
  8. Crea status page pubblica per i clienti.
  9. Aggiungi backup periodico del volume Docker.

Errori comuni e come risolverli

  • Self-hosted sulla stessa infrastruttura: se cade la rete, cade anche il monitor.
  • Troppi monitor per VPS piccolo: Kuma scala bene ma ha limiti su frequency alta.
  • Notifiche non testate: testa ogni canale all'attivazione.
  • Status page non aggiornata: tienila collegata ai monitor reali.

Domande frequenti

D: Conviene avere entrambi?
R: Si: UptimeRobot per controllo indipendente, Kuma per dashboard interna ricca.

D: Quale frequenza di check?
R: 1-3 minuti per servizi critici, 5-15 per il resto.

D: Posso integrare con PagerDuty?
R: Si, entrambi via webhook.

Approfondimento tecnico: nodi distribuiti e status page

Per evitare falsi positivi (un nodo di monitoring offline non implica il sito offline), i servizi seri usano nodi geograficamente distribuiti: UptimeRobot ha 15+ datacenter mondiali, ogni check va da almeno 2 nodi prima di dichiarare down. Self-hosted puoi usare 2-3 VPS in regioni diverse (Hetzner Germania, OVH Francia, DigitalOcean USA) con strumenti come Uptime Kuma cluster mode.

Le status page pubbliche sono parte integrante della comunicazione professionale durante incidenti. Strumenti dedicati: Statuspage.io (Atlassian, a pagamento), Cachet (open source), statping-ng. Buona pratica: comunicare l'incidente entro 5-15 minuti dalla rilevazione, post-mortem trasparente entro 7 giorni.

Scenari d'uso reali

Un SaaS B2B mostra status page pubblica con uptime dei microservizi critici: fiducia rafforzata coi clienti.

Una web agency ha dashboard Kuma interna per tutti i siti clienti: alert Telegram a operatore di turno.

Un e-commerce usa UptimeRobot + Kuma per ridondanza: se uno fallisce, l'altro segnala comunque.

Checklist operativa uptime monitoring

  • Monitor esterno indipendente dall'infrastruttura monitorata.
  • Almeno 2 servizi (SaaS + self-hosted) per ridondanza.
  • Check da regioni diverse per evitare falsi positivi.
  • Frequenza adeguata: 1-3 min critici, 5-15 min secondari.
  • Notifiche multicanale con escalation.
  • Status page pubblica per i clienti.
  • Audit mensile dei monitor (falsi positivi, copertura).

Risorse e riferimenti

uptimerobot.com, github.com/louislam/uptime-kuma. Status page: statuspage.io, cachethq.io, statping.com. Per integration: webhook generici, PagerDuty, Opsgenie, Squadcast. Atlassian Statuspage Standards descrivono incident communication best practice.

Considerazioni economiche e organizzative

Implementare correttamente quanto descritto in questo articolo su monitoring uptime richiede tempo, formazione e talvolta investimenti hardware o software. La buona notizia e che il ritorno e quasi sempre positivo: meno incidenti, meno tempo speso in troubleshooting reattivo, maggiore predicibilita dei servizi. Stima sempre il costo del downtime per il tuo business: anche poche ore l'anno di indisponibilita possono giustificare investimenti che a prima vista sembrano sovradimensionati.

Sul piano organizzativo, la documentazione e il fattore decisivo. Un sistema brillantemente configurato ma non documentato e una bomba a orologeria: il giorno in cui il sysadmin originale lascia l'azienda, ogni intervento diventa archeologia. Mantieni runbook aggiornati, versionali in git, fai pratica di lettura nei momenti di calma e non solo durante gli incidenti.

Glossario rapido dei termini chiave

RTO (Recovery Time Objective): tempo massimo entro cui un servizio deve tornare operativo dopo un'incidente. RPO (Recovery Point Objective): perdita massima accettabile di dati misurata nel tempo (es. 1 ora di transazioni). SLA (Service Level Agreement): contratto formale che definisce livelli di servizio e penali. SLO/SLI (Service Level Objective/Indicator): metriche interne di qualità usate per misurare e mantenere lo SLA. MTBF/MTTR: tempo medio tra guasti e tempo medio di ripristino, indicatori di affidabilità. Idempotenza: proprietà di un'operazione che, applicata più volte, produce lo stesso risultato della singola applicazione (fondamentale per automazione).

Hai bisogno di aiuto?

Se hai dubbi sulla gestione server, il team di G Tech Group puo aiutarti. Contattaci tramite il modulo di contatto.

Hai trovato utile quest'articolo?