Poco prima della mezzanotte, ora del Pacifico, il 19 ottobre 2025, una race condition nell'automazione DNS di Amazon DynamoDB lasciò l'endpoint regionale del servizio in us-east-1 con un record DNS vuoto. Qualsiasi applicazione che richiedesse DynamoDB in quella regione iniziò a fallire e l'impatto si estese a cascata sugli altri servizi AWS dipendenti. Secondo il resoconto ufficiale di AWS, il disservizio durò circa quattordici ore e mezza.
Quella mattina molti team avevano server in perfetto stato. I loro monitor di uptime rimasero verdi mentre il fornitore di identità, la piattaforma di pagamento o il servizio di posta elettronica erano in panne. La maggior parte dei disservizi è più contenuta: il provider di posta accumula quaranta minuti di ritardo, l'assistenza riceve decine di ticket «il link per reimpostare la password non arriva» e alla fine qualcuno scopre la pagina di stato del fornitore, che segna «Prestazioni degradate» già da mezz'ora.
Lavoro in Page Deltas, uno strumento che controlla le pagine web pubbliche e ti avvisa quando cambiano nel modo che ti interessa; tienilo a mente quando più avanti farò confronti con altri strumenti. Questo articolo spiega come orientare il monitoraggio sulle pagine di stato dei fornitori critici: quale URL selezionare, come formulare un brief che elimini il rumore, dove inoltrare le notifiche e quali sono i limiti dell'approccio.
Perché i tuoi sistemi di monitoraggio restano verdi
La tua sonda di uptime verifica semplicemente se il tuo sito risponde, e durante il disservizio di un fornitore terzo generalmente risponde senza problemi. Il tuo APM mostrerà un'impennata di errori sulle chiamate verso quel fornitore, ma non saprà dirti se il problema risiede nel tuo codice o nella loro infrastruttura. È questa la domanda a cui risponde una pagina di stato, e la risposta determina le tue prossime mosse: non esegui il rollback del rilascio fatto un'ora prima; avvisi l'assistenza che si tratta di un problema esterno noto e valuti se aggiornare la tua stessa pagina di stato.
Perché allora non iscriversi direttamente alla pagina del fornitore? Dovresti farlo, se risponde alle tue esigenze. Molte pagine di stato si appoggiano ad Atlassian Statuspage e offrono notifiche via email, SMS, Slack, Teams o webhook, a seconda di cosa il provider abbia attivato. I problemi iniziano con l'ottavo fornitore: ciascuna iscrizione è una procedura a parte che spesso finisce nella casella di posta di un singolo referente, ogni fornitore formatta i messaggi a modo suo e filtrare i soli componenti utilizzati non è sempre consentito. Alcuni fornitori gestiscono persino pagine interne senza alcun tasto di iscrizione.
Un monitor di modifiche web ti garantisce una modalità uniforme per qualsiasi fornitore: incolli l'URL della pagina di stato, descrivi ciò che ti interessa in una frase e ogni notifica arriva nello stesso canale con la medesima struttura.
Quali pagine dovresti monitorare?
Seleziona la pagina che mostra lo stato in tempo reale, solitamente status.fornitore.com. Evita la home page generale o la pagina marketing dedicata all'affidabilità. La maggioranza delle pagine di stato SaaS condivide la stessa struttura: un elenco di componenti con accanto lo stato operativo, un banner per gli incidenti in corso, le manutenzioni programmate e un breve riassunto degli eventi recenti con link all'archivio storico.
Inizia dalle dipendenze di cui i tuoi clienti avvertirebbero subito il blocco. Per gran parte dei team di sviluppo l'elenco è sintetico.
| Dipendenza | Cosa notano i tuoi clienti in caso di disservizio |
|---|---|
| Pagamenti | Il checkout fallisce o i rinnovi non vanno a buon fine |
| Login e autenticazione | Nessuno riesce ad accedere all'account |
| Invio di email e SMS | I messaggi di reset password e gli inviti non arrivano |
| Regione cloud, CDN o DNS | Tutto diventa lento o completamente irraggiungibile |
| API di modelli IA | Le funzionalità di intelligenza artificiale vanno in timeout o restituiscono errori |
Se puoi monitorarne solo alcune, parti dall'alto. I guasti sui pagamenti o sul login si trasformano in ticket di supporto in pochi minuti, mentre una CDN rallentata potrebbe emergere solo dalle metriche interne. I 10 URL del piano gratuito coprono queste cinque voci lasciando spazio per gli elementi illustrati sotto.
Ci sono altre due pagine utili da conoscere. La pagina dell'archivio storico (spesso /history) è un'ottima seconda risorsa per un fornitore critico: un incidente rapido può aprirsi e risolversi tra due controlli della pagina principale, ma rimarrà registrato nello storico consentendoti di analizzarlo in seguito. Durante un disservizio prolungato, puoi aggiungere come monitor temporaneo la pagina specifica dell'incidente per seguirne ogni aggiornamento. Ricordati di eliminarla a incidente chiuso per non occupare la quota di URL.
Configurazione pratica
La configurazione richiede circa cinque minuti e riprende la stessa procedura della nostra guida al monitoraggio dei changelog, con un brief su misura.
1. Crea un account e configura un canale
Registrati gratuitamente, apri Canali e seleziona la destinazione delle notifiche. Ti suggerisco di allestire un canale dedicato come #vendor-status anziché pubblicare in #engineering, dove i messaggi verrebbero sommersi. Slack, Discord e Microsoft Teams richiedono un URL di webhook in ingresso. In Teams, fai clic con il tasto destro sul canale, seleziona Connettori, poi Webhook in ingresso, Configura e incolla l'URL in Page Deltas. Per l'email, il destinatario deve prima convalidare il messaggio di verifica. Clicca su Invia test su ciascun canale per accertarti della corretta ricezione.
2. Aggiungi un monitoraggio con un brief
Clicca su Nuovo monitor e incolla l'URL della pagina di stato. Mantieni un fornitore per monitoraggio così che ogni brief possa citare i singoli componenti pertinenti; se team differenti seguono provider diversi, associa canali distinti a ciascun monitor.
Le pagine di stato mutano più spesso di quanto si creda, anche nelle giornate tranquille: le percentuali di uptime oscillano, i timestamp di «ultimo aggiornamento» avanzano e la lista degli eventi recenti scorre di un giorno con una nuova riga «Nessun incidente segnalato». Le manutenzioni programmate vengono annunciate con settimane di anticipo. Un generico strumento di diff scatterebbe per ciascuna di queste minuzie.
La descrizione del monitor rappresenta il prompt che il nostro LLM analizza per decidere se una variazione sia degna di nota. Formulala come se stessi dando istruzioni a un collega che controlla la pagina al tuo posto. Per un fornitore di posta, un esempio efficace è questo:
Pagina di stato del nostro provider email. Utilizziamo esclusivamente i componenti
Email API e Webhooks, nella regione US.
Avvisami quando viene pubblicato un nuovo incidente che coinvolge quei componenti
o quella regione, quando ne cambia lo stato o la gravità, o quando viene risolto.
Avvisami se uno dei due componenti non è più nello stato Operational.
Ignora percentuali di uptime, timestamp di "ultimo aggiornamento", le righe giornaliere
"Nessun incidente segnalato" e problemi in altre regioni.
Segnala la manutenzione programmata solo se ha inizio entro 48 ore.
Riassumi il componente interessato, lo stato attuale e l'ultimo aggiornamento.La riga con le esclusioni compie la maggior parte del lavoro. Omettendola, passerai la prima settimana a ricevere notifiche a mezzanotte quando la tabella degli eventi scorre in avanti di un giorno.
Per un grande fornitore cloud, specificare regioni e servizi è ancora più vitale. Una dashboard cloud pubblica elenca centinaia di servizi distribuiti su decine di regioni, e in una settimana tipo c'è quasi sempre un componente degradato da qualche parte. Indica espressamente le regioni e i servizi su cui opera la tua infrastruttura e richiedi avvisi solo per quelli.
3. Lascia che il primo controllo fissi la linea base
Un nuovo monitor esegue il primo controllo poco dopo la creazione. Questo passaggio memorizza la situazione di partenza, per cui non riceverai notifiche al primo minuto a meno che la pagina non cambi tra due rilevazioni. Riapri poi il monitor e controlla lo screenshot per accertarti che abbia inquadrato i componenti corretti.
4. Esegui un controllo immediato quando qualcosa non torna
In Page Deltas non si imposta una frequenza fissa. La pianificazione è adattiva: le pagine con frequenti variazioni vengono controllate più spesso e i piani a pagamento hanno priorità nelle code. Poiché una pagina di stato resta calma quasi sempre, se noti un aumento degli errori e sospetti di un fornitore, clicca su Controlla ora sul relativo monitor. L'operazione è accessibile anche tramite API, con il limite di una volta al minuto per monitor:
curl -X POST \
-H "Authorization: Bearer $PAGEDELTAS_TOKEN" \
https://api.pagedeltas.com/api/monitors/$MONITOR_ID/check-nowCosa fare quando arriva una notifica
Quando una variazione corrisponde al tuo brief, ricevi un messaggio unico corredato da un riassunto in linguaggio naturale e dagli screenshot prima e dopo. Se utilizzi il webhook con firma digitale, il corpo del messaggio appare così (i valori sono simulati a scopo illustrativo):
{
"event": "change.detected",
"monitor_id": "01HX7Q...",
"monitor_url": "https://status.example-mail.com/",
"monitor_name": "Stato del fornitore email",
"change_id": "...",
"detected_at": "2026-10-14T07:21:00Z",
"summary": "Nuovo incidente: ritardi nell'invio email nella regione US. Email API è passata da Operational a Degraded Performance. Stato: In corso di analisi.",
"before_screenshot_url": "https://.../before.png",
"after_screenshot_url": "https://.../after.png",
"dashboard_url": "https://app.pagedeltas.com/monitors/..."
}La prima persona che legge la notifica dovrebbe replicare nel thread chiarendo l'impatto sul servizio. Il team di supporto può fissare una nota di disservizio noto prima che i ticket si accumulino. L'ingegnere reperibile può evitare di analizzare un rilascio che non c'entra nulla con gli errori, e se il problema tocca gli utenti finali, aggiorna la tua pagina di stato così che i clienti siano informati tempestivamente da te.
Se il tuo team lavora su PagerDuty o su un altro strumento di incident management, il webhook firmato consente di inoltrare gli eventi tramite un piccolo script serverless. Poiché il nostro payload non ricalca il formato di PagerDuty, bastano poche righe per verificare la firma e smistare l'evento:
import crypto from "node:crypto";
export async function handle(rawBody, signature) {
const expected = "sha256=" + crypto
.createHmac("sha256", process.env.PAGEDELTAS_WEBHOOK_SECRET)
.update(rawBody).digest("hex");
if (signature.length !== expected.length ||
!crypto.timingSafeEqual(Buffer.from(signature), Buffer.from(expected))) {
return 401;
}
const alert = JSON.parse(rawBody);
await fetch("https://events.pagerduty.com/v2/enqueue", {
method: "POST",
headers: { "Content-Type": "application/json" },
body: JSON.stringify({
routing_key: process.env.PAGERDUTY_ROUTING_KEY,
event_action: "trigger",
dedup_key: alert.change_id,
payload: { summary: alert.summary, source: alert.monitor_url, severity: "warning" },
links: [{ href: alert.dashboard_url, text: "Open in Page Deltas" }],
}),
});
return 200;
}Calcola l'hash sul body grezzo prima di effettuarne il parsing JSON, altrimenti la firma non coinciderà. La documentazione sui canali approfondisce tutti i dettagli. Ogni avviso viene spedito una sola volta per canale senza tentativi automatici successivi: per i fornitori insostituibili, affianca un secondo canale di tipo diverso (Slack unito all'email, per esempio) nell'eventualità che Slack o il relè abbiano problemi.
I limiti da considerare
Questa impostazione riporta quanto il fornitore dichiara pubblicamente, e ciò comporta alcuni limiti oggettivi che è bene valutare prima di farvi affidamento esclusivo.
I fornitori spesso impiegano tempo a riconoscere i guasti. I tuoi grafici interni evidenzieranno anomalie talvolta prima che la pagina di stato segnali alcunché: considera quindi l'avviso come una conferma autorevole e non sempre come il primo campanello d'allarme. Inoltre, non sostituisce i test sintetici o il controllo di uptime della tua API: questi ultimi ti dicono che il tuo prodotto non funziona; la pagina di stato ti spiega il perché.
Tra un controllo e l'altro, una modifica viene rilevata al passaggio successivo, senza un intervallo rigido garantito. Per quei due o tre fornitori dove ogni minuto è vitale, mantieni attiva anche la loro notifica diretta e usa Page Deltas per l'intero resto dei servizi. Inoltre monitoriamo solo pagine pubbliche: uno stato visibile unicamente all'interno di una console di amministrazione privata rimane attualmente irraggiungibile.
Il confronto si basa sul testo di ciascuna pagina. Se un fornitore segnala un guasto solo con un pallino colorato senza alterare alcuna parola, non potremo rilevarlo. Visualping permette di monitorare una porzione grafica di pixel ed è più adatto in quella specifica circostanza. Infine, se è la pagina di stato stessa ad andare offline, i controlli falliscono anziché generare un avviso, e dopo 10 fallimenti consecutivi il monitoraggio va in pausa automatica avvertendo gli amministratori.
Inizia con tre fornitori
Individua i tre fornitori la cui caduta ti creerebbe il danno maggiore: solitamente pagamenti, autenticazione e posta elettronica. Incolla gli URL delle loro pagine di stato, adatta il brief con i componenti e le regioni che usi, e invia un messaggio di prova su #vendor-status. Il piano gratuito include 10 URL con filtro IA, tutti i canali di notifica e accesso API, senza richiedere alcuna carta di credito. Inizia a monitorare gratuitamente.
Julien, Product Manager di Page Deltas