Monitorare l'Uptime di un Sito Web e Inviare Alert

Se il tuo sito o una landing non rispondono quando una campagna è live, bruci budget e opportunità. Con monitor uptime sito con n8n puoi costruire un sistema di monitoraggio disponibilità siti web completamente personalizzabile: controlli periodici, allerta downtime automatica, logging su fogli di calcolo e notifiche su Slack/Email/Telegram, con deduplicazione delle segnalazioni e finestre di manutenzione per evitare falsi positivi. In questa guida realizzerai un workflow n8n HTTP check che verifica codice di stato (200/503), misura trend, scrive log puliti su Google Sheets e invia avvisi al team solo quando serve. Vedremo componenti e best practice (retry e backoff nei monitoraggi, soglie e conferme, MTTR e MTBF per servizi web), oltre a varianti avanzate come monitoraggio multi‑sito con fogli di calcolo e pagina di stato con GitHub Pages. Obiettivo: una pipeline affidabile, economica e sotto il tuo pieno controllo.

📚 Nuovo a n8n? Parti dalla guida completa: cos’è n8n e come funziona.

Perché costruire un monitor con n8n: vantaggi e casi d’uso

Vantaggi rispetto a soluzioni SaaS (costi, controllo, personalizzazione)

Costi e controllo: nessun canone per host/endpoint extra, puoi definire la frequenza e la logica come vuoi.
Personalizzazione: alert su misura, routing avanzato, integra con i tuoi strumenti senza vincoli.
Dati di proprietà: storico uptime/latency e incidenti nei tuoi fogli/DB, pronti per BI.

Casi d’uso tipici: siti, API, microservizi, landing critiche

Landing di performance ads, API pubbliche, microservizi interni, pagine di pagamento o funnel di lead gen. Puoi distinguere severità (es. API core vs blog) e trattare gli alert in modo differenziato (escalation solo per servizi critici).

Insight pratico

Per ridurre falsi positivi, non basta un controllo singolo: usa retry con backoff e soglie (es. 2 fallimenti su 3 in una finestra), più contenuto atteso (keyword) e latenza. Così avvisi il team solo quando il problema è reale e impattante.

Componenti del workflow e logica UP/DOWN

Componenti chiave: Schedule, HTTP Request, Switch/IF, Code, connettori email/Slack/Telegram

Scheduler: esegue i check a intervalli regolari (2–5 minuti per le landing critiche).
HTTP Request: invoca le URL da monitorare e verifica il controllo stato HTTP 200/503 (e altri codici).
IF/Switch: instrada UP/DOWN e imposta severità.
Code: calcola dedup, durata, finestre di manutenzione programmata.
Notifiche: Slack/Email/Telegram per alert e ripristini.
Google Sheets: storage per logging uptime su Google Sheets e stato corrente.

Logica UP/DOWN, gestione errori e timeout

UP quando status 200 e contenuto atteso presente.
DOWN se 5xx, timeout o keyword mancante.
Errori temporanei: applica retry e backoff con soglie di conferma (es. 2/3 tentativi falliti in 90 secondi).
Timeout: meglio breve (3–5 s) per rilevare blocchi senza accumulare code.

Creare il flusso base: scheduler, HTTP check, log, alert

Creazione del flusso base

Frequenza: imposta il trigger del workflow ogni 2–5 minuti (in produzione, separa i flussi per URL critiche vs non critiche).
Lista URL: inizia con un array nel nodo Code o leggi da un foglio Google Sheets (poi scala a monitoraggio multi‑sito con fogli di calcolo).
Check: per ogni URL, esegui un HTTP GET e valuta lo stato e, facoltativamente, una parola chiave nella pagina.

HTTP GET con “n8n-nodes-base.httpRequest”

{
  "name": "HTTP GET Example",
  "type": "n8n-nodes-base.httpRequest",
  "typeVersion": 1,
  "parameters": {
    "url": "https://example.com/health",
    "method": "GET",
    "queryParametersUi": {
      "parameter": [
        { "name": "check", "value": "uptime" }
      ]
    }
  }
}

Logging su Google Sheets (Append)

{
  "name": "Append To Sheet",
  "type": "n8n-nodes-base.googleSheets",
  "typeVersion": 4,
  "parameters": {
    "operation": "append",
    "spreadsheetId": "1A2b3C4D5E6FgHiJkLMnoPQrstu",
    "sheetName": "Uptime_Log",
    "dataMode": "autoMap",
    "options": { "valueInputMode": "USER_ENTERED" }
  },
  "credentials": {
    "googleSheetsOAuth2Api": { "name": "Google Sheets OAuth2" }
  }
}

Notifica Slack (Send Message)

{
  "name": "Send Slack Message",
  "type": "n8n-nodes-base.slack",
  "typeVersion": 1,
  "parameters": {
    "resource": "message",
    "operation": "send",
    "channel": "C01234567",
    "text": "ALERT: {{ $json.url }} è DOWN (status: {{ $json.statusCode || 'timeout' }})"
  },
  "credentials": {
    "slackApi": { "name": "Slack OAuth2" }
  }
}

Suggerimenti operativi

Scrivi nel log: timestamp, url, status, esito, eventuale latenza (se calcolata a valle), messaggio/errore.
Invia alert solo alla prima conferma del DOWN; silenzia alert ripetuti finché lo stato non torna UP.

Prevenire falsi positivi: retry, backoff, conferme e finestre

Prevenire falsi positivi: retry, backoff, soglie e finestre di conferma

Retry: ripeti il check subito 1–2 volte. Usa backoff (es. +10s) e aggiungi jitter casuale.
Conferme: apri l’incidente se falliscono X tentativi su Y in una finestra (es. 2/3 in 90s).
Contenuto atteso: oltre al 200, cerca una keyword nel body per evitare “false UP” con pagine di errore brandizzate.
Latenza: se supera soglie (es. >2s per una landing), imposta warning (non critico).

Finestre di manutenzione programmata

Definisci intervalli in cui il sito è volutamente down (deploy/maintenance). In queste finestre, disattiva gli alert ma continua a loggare per completezza.
Mantieni elenco finestre in un foglio dedicato, letto dal workflow per decidere se silenziare gli avvisi.

Esempio di dedup semplice (Code)

// Evita alert ripetuti: segnala solo se lo stato cambia
const state = $json.state || 'UNKNOWN';  // UP/DOWN precedente (recupera da Sheets/DB)
const current = $json.current || 'DOWN'; // risultato attuale
if (state === current) {
  return []; // nessun alert
}
return [{ json: { ...$json, changed: true } }];

Monitoraggio multi‑sito e logging strutturato

Monitorare più siti da Google Sheets (scalare da 1 a 100+ URL)

Mantieni una tabella Sites con colonne: url, keyword, criticality, team_channel, enabled.
Il workflow legge l’elenco, esegue loop sui siti enabled e applica policy per‑sito (frequenza, parole chiave, canale Slack).
Log su due sheet: Alive (UP) e Down (DOWN) per separare lo storico e facilitare calcoli.

Strutturare i log: separare “Alive/Down”, storico, calcolo uptime

Per ogni check salva: timestamp ISO, url, statusCode, outcome (UP/DOWN/WARN), retries, note.
Calcola uptime % per giorno/settimana (conta UP/total). Aggiungi trend e rolling average.
Tieni un foglio Incidents per eventi aperti/chiusi con durata: utile per MTTR e MTBF.

Notifiche efficaci: Email/Slack/Telegram, severità e anti‑spam

Email, Slack e Telegram: formattazione messaggi, severity, menzioni

Testo breve e azionabile: URL, stato, codice, durata stimata, link diagnostici (ping, traceroute, status page).
Severity: CRITICO per siti revenue‑driven, WARNING per pagine non core.
Menzioni mirate: @channel solo per incidenti critici; DM all’on‑call per escalation.

Chiamate vocali/escalation e regole anti‑spam (dedup/throttling)

Per incidenti critici, integra una chiamata vocale (es. provider VoIP) dopo X minuti DOWN.
Throttling: non inviare più di un alert ogni N minuti per la stessa URL.
Alert di ripristino: invia un messaggio “RECOVERY” quando torna UP, con durata totale.

Esempio messaggio Slack

{
  "text": "RECOVERY: {{ $json.url }} è di nuovo UP (durata incidente: {{ $json.incidentDuration || 'n/a' }})."
}

Status page automatica con GitHub Pages

Status page automatica con GitHub Pages (aggiornamento index.html)

Strategy: ogni volta che cambia lo stato di un servizio, aggiorna un file index.html nel repository e committa/pusha. GitHub Pages renderà la pagina pubblica.
Contenuto: elenco servizi con badge UP/DOWN/WARN, timestamp ultimo aggiornamento e link alla cronologia.
Workflow: al cambio stato → genera HTML (Code), commit via integrazione GitHub → push.
Vantaggi: trasparenza con utenti e stakeholder, riduce il carico su support in caso di incidenti.

KPI e miglioramento continuo: uptime, MTTR, MTBF e falsi positivi

KPI da tracciare: uptime %, MTTR, MTBF, tasso falsi positivi

Uptime %: UP/total checks. Segmenta per sito/criticità.
MTTR: tempo medio di ripristino dagli incidenti.
MTBF: tempo medio tra i guasti.
Tasso falsi positivi: incidenti aperti/chiusi <2 min o senza impatto misurabile.

Migliorare con i dati

Se molti falsi positivi, aumenta conferme o raffina keyword/timeout.
Se MTTR alto, aggiungi escalation o playbook con check diagnostici automatici (es. check DNS, porta, dipendenze).

Sicurezza e governance

Sicurezza: gestione segreti, permessi, rate limit API

Conserva credenziali (Gmail/Slack/Telegram/Sheets) in vault/variabili ambiente sicure.
Limita permessi in n8n (chi può modificare workflow/credenziali).
Rispetta rate limit delle API esterne (soprattutto su grandi fleet di URL): usa batch e intervalli.

Test, deploy e monitoraggio del workflow (self‑hosted vs n8n Cloud)

Testa in sandbox con pochi siti; aumenta poi la frequenza.
In self‑hosted, metti n8n dietro un reverse proxy e monitora risorse (CPU/RAM) quando la lista cresce.
In n8n Cloud, sfrutta affidabilità gestita e semplifica setup credenziali.

Performance e scaling

Performance e scaling: batch/concurrency, code execution, limiti di Google Sheets e alternative (DB, Airtable)

Con molti siti, suddividi in batch (per criticità) e sfasa gli orari per evitare burst.
Google Sheets ha limiti: quando superi ~5–10k righe/giorno, valuta DB gestito o Airtable per log.
Usa trasformazioni leggere e filtra presto (non loggare ogni “UP” se ridondante; salva solo cambi di stato + heartbeat aggregati).

Esempi pronti: configurazioni n8n riutilizzabili

HTTP Request (GET) — check salute

{
  "name": "HTTP GET Example",
  "type": "n8n-nodes-base.httpRequest",
  "typeVersion": 1,
  "parameters": {
    "url": "https://example.com/health",
    "method": "GET"
  }
}

Google Sheets (Append) — scrittura log

{
  "name": "Append To Sheet",
  "type": "n8n-nodes-base.googleSheets",
  "typeVersion": 4,
  "parameters": {
    "operation": "append",
    "spreadsheetId": "1A2b3C4D5E6FgHiJkLMnoPQrstu",
    "sheetName": "Uptime_Log",
    "dataMode": "autoMap",
    "options": { "valueInputMode": "USER_ENTERED" }
  }
}

Slack (Send) — alert

{
  "name": "Send Slack Message",
  "type": "n8n-nodes-base.slack",
  "typeVersion": 1,
  "parameters": {
    "resource": "message",
    "operation": "send",
    "channel": "C01234567",
    "text": "ALERT: {{ $json.url }} è DOWN (status: {{ $json.statusCode || 'timeout' }})"
  }
}

Quick Takeaways

Con monitor uptime sito con n8n costruisci un monitor flessibile: scheduli i check, analizzi status/keyword e invii alert mirati.
Prevenire falsi positivi è cruciale: retry, backoff, soglie di conferma, keyword e finestre di manutenzione.
Log ben strutturati su Google Sheets/DB abilitano KPI (uptime, MTTR, MTBF) e miglioramenti continui.
Notifiche multi‑canale (Slack/Email/Telegram) con severità e dedup riducono il rumore e accelerano la risposta.
Scala a decine/centinaia di URL con batch, rate limit e storage adeguato; usa una status page con GitHub Pages per trasparenza.

Conclusione

Un monitor di uptime efficace non è solo “pingare” una pagina: serve distinguere tra errori reali e rumore, notificare le persone giuste con il giusto livello di urgenza, e registrare dati che guidino miglioramenti. Con monitor uptime sito con n8n ottieni tutto questo: controlli periodici affidabili, allerta downtime automatica con deduplicazione e finestre di manutenzione, logging strutturato e KPI operativi. Partendo da un semplice HTTP check e da log su Google Sheets, puoi espandere verso monitoraggio multi‑sito, pagina di stato pubblica e processi di escalation per i servizi critici. Il valore per i marketer è immediato: campagne più sicure, meno budget sprecato e una risposta rapida ai problemi che contano. Inizia con 3–5 URL fondamentali, imposta retry e soglie, aggiungi Slack e un foglio log; poi scala il modello alle altre proprietà digitali del tuo brand.

FAQ

Posso monitorare più URL in un unico workflow?

Sì, lega un elenco di URL in un foglio e cicla dinamicamente: registri ogni esito e invii avvisi solo sugli incidenti, abilitando monitoraggio multi‑sito con fogli di calcolo e alert per‑sito.

Come evito falsi positivi negli alert?

Usa retry e backoff nei monitoraggi, soglie (2/3 tentativi falliti), keyword di contenuto e finestre di manutenzione programmata per silenziare gli avvisi nelle ore previste.

Come salvo lo storico e calcolo uptime/MTTR/MTBF?

Logga UP/DOWN con timestamp su Google Sheets o DB. Con query/pivot calcoli uptime %, durata incidenti (MTTR) e intervallo medio tra guasti (MTBF).

Posso inviare alert su Slack, Email o Telegram?

Sì. Configura avvisi email Slack Telegram e differenzia la severità: CRITICO vs WARNING. Imposta deduplicazione notifiche incidenti e invia messaggi di ripristino.

È possibile una status page pubblica?

Sì. Aggiorna automaticamente un index.html su GitHub Pages con lo stato per‑servizio e timestamp ultimo aggiornamento, così gli stakeholder hanno visibilità istantanea.

Ci dai una mano?

Quale URL monitorerai per primo e con quali soglie di alert? Condividi la tua strategia e passa questo articolo al team: costruiamo insieme un monitor leggero, affidabile e fatto su misura!

Monitorare l’Uptime di un Sito Web e Inviare Alert