Uno SLA al 99,9% — il valore dichiarato dalla maggior parte dei servizi cloud gestiti — lascia comunque spazio a circa 43 minuti e 50 secondi di indisponibilità al mese. Il punto è che quei 43 minuti non si distribuiscono gentilmente alle 4 del mattino: possono cadere tutti insieme durante l’invio della newsletter o il picco serale di un e-commerce.
Risposta diretta: se il container server non risponde, il browser continua a inviare le hit verso il tuo endpoint, ma quelle richieste falliscono e nella quasi totalità dei casi non vengono ritentate. I dati di quella finestra temporale sono persi in modo definitivo. Il sito però non si rompe: le richieste al container server sono asincrone e indipendenti dal rendering della pagina, l’utente non vede errori e il checkout continua a funzionare.
Seconda precisazione, altrettanto importante: non perdi "tutto il tracciamento". Perdi solo ciò che transita dal container server. I tag ancora lato client puro — pixel di terze parti non migrati, strumenti di heatmap, un GA4 web lasciato in parallelo — continuano a lavorare senza accorgersi di nulla.
Il container server di Google Tag Manager server-side (sGTM) è un’applicazione in esecuzione su un server, tipicamente Google Cloud Run o un hosting gestito, che riceve le richieste del sito su un sottodominio di primo livello e le inoltra a GA4, Google Ads, Meta e altre destinazioni. Quando quell’applicazione smette di rispondere, salta l’anello centrale della catena.
I cinque scenari di "offline" che non sono la stessa cosa
"Il container è giù" descrive situazioni molto diverse tra loro, con danni e sintomi differenti.
Scenario 1 — Servizio down o istanze a zero. Il container non risponde: timeout o errore 5xx. Perdita totale delle hit nella finestra.
Scenario 2 — Saturazione o cold start. Il servizio è vivo ma risponde oltre i tempi utili, con 429 o 503 nei picchi. Perdita parziale e selettiva, proprio nei minuti in cui il traffico vale di più.
Scenario 3 — Certificato SSL scaduto o DNS non risolto. L’applicazione gira benissimo, ma il browser blocca la richiesta prima di inviarla. È il guasto più frequente e il più silenzioso, e nasce quasi sempre da una gestione approssimativa del dominio personalizzato del container server.
Scenario 4 — Container vivo ma muto. Risponde 200, ma dopo una pubblicazione sbagliata o un ID contenitore errato non inoltra nulla alle destinazioni. È il caso peggiore: ogni uptime check ti dice che va tutto bene.
Scenario 5 — Preview sì, produzione no (o viceversa). L’endpoint di debug e quello di produzione sono due cose distinte: il Tag Assistant che funziona non è la prova che la produzione stia ricevendo.
| Scenario | Risposta tipica | Il sito si rompe? | Dati persi | Lo vede un uptime check? |
|---|---|---|---|---|
| Servizio down | 5xx / timeout | No | Tutti | Sì |
| Saturazione / cold start | 429, 503, latenza alta | No | Parziali, sui picchi | Solo se misuri la latenza |
| SSL o DNS | richiesta bloccata dal browser | No | Tutti | Sì, se controlli il dominio e non l’URL del servizio |
| Vivo ma muto | 200 | No | Tutti, in silenzio | No |
| Preview/produzione disallineati | 200 | No | Dipende | No |
Quali dati perdi e quali sopravvivono
Prima della tabella, il principio che governa tutto: conta la direzione della richiesta. Browser → container server significa nessuna coda e nessun retry: se fallisce, è finita. Server → container server o container server → piattaforma significa che da qualche parte esiste un mittente che può riprovare.
I flussi che muoiono in silenzio
Le hit GA4 che passano dal client GA4 del container partono dal browser verso il tuo sottodominio. gtag.js non ha un buffer persistente: se la richiesta fallisce, l’evento non esiste più. Stesso destino per il conversion linker e per le conversioni Google Ads inviate dal server: la conversione non viene registrata nel momento in cui avviene, con effetto immediato su attribuzione e offerte automatiche.
I flussi che hanno una rete di sicurezza
Meta Conversions API (CAPI, l’invio server-to-server degli eventi a Meta) è il caso più interessante. Se tieni attivo anche il pixel browser con lo stesso event_id, l’evento arriva comunque dal client e la deduplicazione tra browser e server fa il resto quando il container torna online. È la forma di failover più economica che esista.
Poi ci sono le chiamate server-to-server dirette al container: Measurement Protocol, webhook di Shopify, callback di pagamento di WooCommerce o PrestaShop. Molti di questi mittenti ritentano in caso di 5xx (Shopify, per esempio, ripete la consegna dei webhook falliti), altri no. Verifica la retry policy di ogni integrazione: è l’unico modo per sapere in anticipo cosa sopravvive.
| Flusso | Origine richiesta | Retry? | Recuperabile dopo? | Impatto campagne |
|---|---|---|---|---|
| GA4 via client GA4 | browser | No | No | Report e pubblici incompleti |
| Google Ads conversioni + Enhanced Conversions | browser → server | No | Parziale, via upload offline | Alto, immediato |
| Meta CAPI con pixel in parallelo | server | No, ma copre il pixel | Sì, di fatto | Basso |
| Measurement Protocol / webhook e-commerce | server | Spesso sì | Sì | Medio |
| Segnali Consent Mode v2 | browser | No | No | Modellazione meno accurata |
Una nota onesta: le hit browser perse non si recuperano. Punto. Puoi ricostruire solo ciò che esiste già nel gestionale o nel database dell’e-commerce, cioè in pratica gli ordini.
Quanto costa davvero un’ora di downtime
Stimarlo richiede tre dati che hai già.
- Eventi o sessioni per fascia oraria, presi da un’esplorazione GA4 sullo stesso giorno della settimana nelle quattro settimane precedenti.
- Tasso di conversione medio in quella fascia.
- Valore medio ordine.
Esempio puramente illustrativo: un e-commerce con 1.200 sessioni al giorno, di cui circa il 15% concentrate tra le 20 e le 22, perde in due ore di down serale circa 180 sessioni tracciate. Con un tasso di conversione dell’1,5% parliamo di due o tre conversioni che non arrivano a Google Ads, oltre a tutti gli eventi di carrello e checkout che alimentano i pubblici.
Il danno vero non è il buco nel report mensile. Sono i segnali mancanti per Target ROAS e Target CPA: l’algoritmo apprende su finestre di più giorni, quindi reagisce in ritardo rispetto all’incidente e tu vedi lo scostamento quando il problema è già risolto da 48 ore. Chi lavora sulle performance sa quanto questo sporchi l’analisi: il tema è lo stesso delle conversioni Google Ads che non corrispondono a GA4.
Venti minuti alle 4 del mattino e venti minuti durante il lancio di una campagna non sono lo stesso evento. Misura il downtime in traffico perso, non in minuti.
Come ti accorgi che il container è offline prima che te lo dica il cliente
Servono tre livelli, perché nessuno dei tre copre tutto da solo.
Livello 1 — Uptime check esterno
Controlla l’endpoint /healthz del container, ogni minuto, chiamandolo sul dominio personalizzato e non sull’URL interno del servizio: così intercetti anche SSL e DNS. Alert su e-mail e Slack. Verifica codice 200 e tempo di risposta, con soglia esplicita (per esempio 2 secondi). Questo livello non vede lo Scenario 4.
Livello 2 — Metriche dell’infrastruttura
Su Cloud Run tieni d’occhio quattro valori: conteggio richieste, percentuale di risposte 5xx, latenza al 95° percentile e numero di istanze attive. Imposta un alert quando le 5xx superano una soglia bassa (1-2% su finestra di 5 minuti) e quando il conteggio richieste crolla rispetto all’atteso: il calo di traffico è un sintomo tanto quanto l’errore.
Livello 3 — Anomalia sul volume di eventi
È l’unico controllo che smaschera il container vivo ma muto. Due strade: il rilevamento anomalie su un’esplorazione GA4, oppure una query schedulata che confronta gli eventi orari con la media delle quattro settimane precedenti se hai già lo streaming degli eventi del container su BigQuery.
Aggiungi due presidi banali e molto efficaci: scadenza del certificato e record DNS in calendario con promemoria a 30 giorni, e un controllo incrociato settimanale tra ordini a gestionale, conversioni GA4 e conversioni Google Ads. Uno scostamento improvviso tra queste tre colonne è l’allarme più economico che puoi implementare.
La procedura di ripristino in sette passi
- Isola il guasto. Chiama l’URL del servizio sottostante e poi il dominio personalizzato. Se il primo risponde e il secondo no, il problema è DNS o SSL, non applicativo.
- Leggi i log delle ultime ore e individua l’orario esatto di inizio e il codice di errore ricorrente.
- Controlla le pubblicazioni recenti, sia del container server sia di quello web. Il rollback alla versione precedente è la prima mossa, non l’ultima: ripristini subito e indaghi dopo.
- Verifica quote e scalabilità: istanze massime raggiunte, memoria insufficiente, istanze minime a zero.
- Ridistribuisci il servizio con l’immagine ufficiale aggiornata del container sGTM.
- Documenta la finestra esatta di down, inizio e fine. Serve per annotarla in GA4 e per spiegare lo scostamento nel report mensile senza dover improvvisare.
- Valuta il recupero selettivo dei soli dati ricostruibili: ordini presenti a gestionale reinviati via Measurement Protocol, oppure upload di conversioni offline in Google Ads. Attenzione alle finestre temporali di importazione e al fatto che l’attribuzione non sarà identica all’originale.
Configurazioni che reggono l’imprevisto
Qui ho un’opinione netta: impostare le istanze minime a zero per risparmiare qualche euro è la causa numero uno di hit perse. Il cold start di un container sGTM non è istantaneo e il primo picco di traffico dopo un periodo di inattività è esattamente quello che paghi di più in advertising. Se hai dubbi sull’ordine di grandezza della spesa, i numeri reali sono qui: quanto costa un container server-side.
Altre scelte che fanno la differenza:
- Numero massimo di istanze dimensionato sui picchi reali, non sulla media mensile.
- Pixel browser Meta attivo in parallelo alla CAPI con
event_idcondiviso: ridondanza a costo quasi zero. - Ambiente di preview separato dalla produzione e nessuna pubblicazione in orario di picco. Finestra di deploy al mattino presto, mai il venerdì pomeriggio.
- Ridondanza multi-region e load balancer: ha senso sopra certi volumi, è sovradimensionato per la PMI media.
| Opzione | Chi garantisce l’uptime | Chi monitora | Chi interviene di notte | Competenza richiesta |
|---|---|---|---|---|
| Cloud Run self-managed | tu, sopra lo SLA Google | tu | tu | Alta (cloud, DNS, log) |
| Hosting gestito per sGTM | il fornitore | il fornitore + tu | il fornitore | Media |
| VPS o server dedicato | tu | tu | tu | Molto alta |
Il confronto operativo tra le prime due opzioni è approfondito nell’articolo su Google Cloud Run e hosting gestito per il container server, mentre i criteri generali di scelta dell’infrastruttura li trovi nella guida su cosa fa davvero l’hosting del container server-side.
Ultima cosa sugli SLA: coprono l’infrastruttura, non la tua configurazione. Un container pubblicato male resta un problema tuo al 100%.
Downtime, consenso e GDPR: cosa cambia e cosa no
Un container offline non genera di per sé un problema di conformità: semplicemente non raccogli dati. Il rischio nasce nel recupero a posteriori. Non puoi reinviare via Measurement Protocol o caricare come conversioni offline gli eventi di utenti che non avevano prestato consenso: il fatto che l’ordine esista a gestionale non trasforma quel dato in dato trattabile per finalità di marketing.
Consent Mode v2 continua a funzionare lato browser anche durante il down: i segnali di consenso restano corretti, semplicemente non raggiungono la destinazione. Quando ripristini, verifica che il consenso venga rispettato prima di qualunque operazione di backfill.
Se l’incidente è prolungato, annota nella documentazione tecnica la finestra, i flussi coinvolti e le eventuali operazioni di recupero effettuate. Serve a te sei mesi dopo, quando qualcuno chiederà perché quella settimana ha numeri strani.
Se gestisci un solo sito, i tre livelli di monitoraggio li imposti in un pomeriggio. Se segui più container per clienti diversi, il discorso cambia: servono alert centralizzati, runbook condivisi e una decisione esplicita su chi risponde alle 23 di sabato. In quel caso vale la pena farsi affiancare nella progettazione del failover invece di scoprirlo in emergenza.
Domande frequenti
Se il container server va offline, il mio sito smette di funzionare o rallenta?
No. Le richieste verso il container server-side sono asincrone e non bloccano il rendering della pagina: l’utente naviga, aggiunge al carrello e completa il checkout senza vedere errori. L’unica eccezione riguarda configurazioni in cui il container serve anche risorse del sito (per esempio lo script gtag.js proxato): in quel caso lo script non viene caricato, ma la pagina resta comunque funzionante.
I dati persi durante il downtime del container server si possono recuperare?
Solo in parte. Le hit partite dal browser verso il container non hanno retry né coda: una volta fallite sono perse definitivamente. Puoi ricostruire soltanto gli eventi che esistono anche altrove, tipicamente gli ordini presenti nel gestionale o nel backoffice dell’e-commerce, reinviandoli via Measurement Protocol o come conversioni offline in Google Ads, nel rispetto del consenso raccolto e delle finestre temporali di importazione.
Perché il mio container server risponde 200 ma GA4 non registra più eventi?
È lo scenario del container vivo ma muto: l’applicazione è attiva e l’endpoint /healthz risponde correttamente, ma i tag non inoltrano nulla alle destinazioni. Le cause più comuni sono una pubblicazione sbagliata del container server, un ID di misurazione o un ID contenitore errato, un client GA4 disattivato o un’eccezione di trigger introdotta per errore. Nessun uptime check lo rileva: serve un controllo sul volume di eventi in GA4 o in BigQuery.
Quanto downtime è accettabile per un container server-side?
Non esiste una soglia universale: dipende da quanto traffico passa in quella finestra. Un’indisponibilità di venti minuti alle 4 del mattino su un sito italiano è quasi irrilevante, gli stessi venti minuti durante un lancio o un picco serale costano conversioni e segnali di apprendimento alle campagne. Ragiona in percentuale di sessioni perse sul mese, non in minuti assoluti, e imposta gli alert perché il tempo di rilevamento resti sotto i cinque minuti.