Server-side GTM monitoren: vier alerting-policies voor Cloud Run die je nu moet instellen
Een server-side Google Tag Manager-setup op Google Cloud Run beheert zichzelf niet vanzelf. Met health checks, budgetwaarschuwingen en vier gerichte alerting-policies in Cloud Monitoring voorkom je dat een stille storing of onverwachte kostenpiek je dataverzameling onderuithaalt. Dit artikel beschrijft welke monitoring je minimaal moet inrichten en welke drempelwaarden als vertrekpunt dienen.
Waarom sGTM-infrastructuur actieve monitoring vereist
Server-side tagging draait op cloud-infrastructuur die je zelf beheert. Dat betekent dat je ook zelf verantwoordelijk bent voor de beschikbaarheid van het tagging-endpoint. Bij stabiel, voorspelbaar verkeer is de setup relatief onderhoudsvriendelijk, maar zodra verkeerspieken mogelijk zijn, heb je alerting nodig. Zonder monitoring merk je een storing of capaciteitsprobleem pas als de data al uren ontbreekt in GA4 of Meta CAPI — of als de factuur onverwacht hoog uitvalt.
Stap 1: Health checks op Cloud Run
Google Cloud Run biedt twee typen health checks die je per service configureert via 'Edit & Deploy New Revision'. De startup probe controleert of de service correct is opgestart; bij een negatieve respons wordt de service herstart en haalt hij automatisch de nieuwste runtime op van Google. De liveness probe controleert daarna periodiek of de service blijft reageren. Voor de startup probe gebruik je TCP op poort 8080, met een initial delay van 0, een period van 240 seconden, een failure threshold van 1 en een timeout van 240 seconden. De liveness probe werkt via HTTP op het pad /healthy, poort 8080, met een initial delay van 30 seconden, period van 10 seconden, failure threshold van 3 en timeout van 1 seconde. Voeg beide probes toe aan elke Cloud Run-service die je wilt bewaken — bij een multi-service setup met een global load balancer geldt dat dus voor elke afzonderlijke service. De preview-service laat je doorgaans weg, omdat die zelden overbelast raakt.
Stap 2: Budget- en factuurwaarschuwingen
Stel via de Billing-console een projectspecifiek budget in dat ruim boven je verwachte maandelijkse kosten ligt. Bij een typische uitgave van circa 110 euro per maand is 150 euro een redelijke bovengrens. Standaard ontvang je meldingen bij 50%, 90% en 100% van het budget op basis van werkelijke uitgaven; je kunt ook overschakelen naar prognose-gebaseerde waarschuwingen voor een eerder signaal. Belangrijk: een budget stopt de uitgaven niet automatisch — het is uitsluitend een meldmechanisme.
Stap 3: Vier alerting-policies in Cloud Monitoring
Cloud Monitoring laat je op basis van metrische drempelwaarden automatisch waarschuwingen versturen. De vier onderstaande policies vormen een praktisch startpunt. **1. HTTP-fouten op kritieke paden.** Maak een log-based metric in Logs Explorer met een query die HTTP-statuscodes van 400 of hoger filtert op de paden /gtm.js, /gtag/ en /g/collect (of de paden die jouw setup gebruikt, zoals een Stape Data Tag-endpoint). Gebruik resource.type='http_load_balancer'; zonder load balancer vervang je dat door 'cloud_run_revision'. Stel de alerting policy in op een rate van 5 verzoeken per seconde over een rolling window van 5 minuten. Op een site met weinig verkeer wil je deze drempel lager zetten. **2. CPU-gebruik van de container.** Gebruik de metric Container CPU Utilization. Cloud Run probeert het CPU-gebruik onder de 60% te houden door automatisch extra instanties op te starten. Als dat niet lukt — bijvoorbeeld omdat je het maximum aantal instanties hebt bereikt — stijgt het gebruik daarboven. Stel de alert in op gemiddeld CPU-gebruik boven 60% over 5 minuten, zodat je tijdig het maximumaantal instanties kunt verhogen. **3. Aantal actieve instanties.** Monitor de instance_count-metric voor Cloud Run. Bij een aanbevolen maximum van 10 instanties is een drempel van 8 (80%) een zinvol signaal om alvast een nieuwe revisie te deployen met een hogere limiet. Stel de trigger in op 'any time series violation', zodat elke Cloud Run-service de alert kan activeren. **4. Requestlatency.** Hoge latency duidt op overbelasting. Gebruik de request_latencies-metric voor Cloud Run Revision, kijk naar het gemiddelde over 5 minuten en stel de drempel in op 2000 milliseconden. Zodra de gemiddelde responstijd structureel boven 2 seconden uitkomt, is actie nodig.
Wat je nu moet controleren en instellen
Controleer voor elke Cloud Run-service of beide health checks aanwezig zijn en of de instellingen overeenkomen met de bovenstaande waarden. Verifieer daarna of er een projectspecifiek budget is aangemaakt in de Billing-console. Maak vervolgens de vier alerting-policies aan in Cloud Monitoring en pas de drempelwaarden aan op het verwachte verkeersvolume van jouw setup — de genoemde waarden zijn vertrekpunten, geen universele normen. De drempelwaarden voor CPU, instantieaantal en latency hangen direct samen met de configuratie van je Cloud Run-services. Pas ze aan zodra je een beter beeld hebt van het normale gedrag van je setup. Cloud Monitoring biedt daarnaast experimentele 'Forecasted metric-value'-policies waarmee je nog eerder gewaarschuwd kunt worden; die zijn momenteel beschikbaar voor testing. Als je server-side GTM draait in een zelfbeheerde cloudomgeving, is monitoring geen optionele extra — het is een basisvereiste voor betrouwbare dataverzameling.