Zo verminder je valse meldingen bij uptime monitoring: bevestig elke fout met een tweede check voordat je alarm slaat, stel time-outs in die passen bij hoe je site zich normaal gedraagt, controleer op een verwachte statuscode en inhoud op een URL die de dienst echt weerspiegelt, stuur de meldingen van elke monitor alleen naar mensen die er iets mee kunnen, zet gepland werk in een onderhoudsvenster en kondig het aan, en bekijk elke maand de monitors met de meeste ruis. De meeste valse meldingen komen van een handvol monitors waarbij een van deze instellingen niet klopt, dus het oplossen gaat meestal snel.
In deze gids lees je waarom valse meldingen gevaarlijk zijn, waar ze vandaan komen en wat je per instelling aanpast.
Waarom valse meldingen erger zijn dan ze lijken
Eén valse melding is een kleine ergernis. Een gestage stroom ervan is alert fatigue: mensen zetten het kanaal op stil, filteren de e-mails naar een map of werpen een blik op hun telefoon en slapen verder. De monitoring draait nog, maar niemand luistert. De eerste echte storing daarna wordt op de ouderwetse manier ontdekt: door een klant.
Er is ook een minder zichtbare prijs. Elke valse melding haalt iemand uit zijn werk om een site te controleren die prima werkt. Over een maand loopt dat op tot uren verloren focus en een team dat zijn tools minder vertrouwt. Het doel is niet minder meldingen omwille van minder meldingen. Het doel is meldingen die het elke keer waard zijn om te lezen.
Waar valse meldingen vandaan komen
Netwerkhaperingen tussen één checklocatie en je server: een verloren pakket, een trage route, een korte DNS-hapering.
Te krappe time-outs voor een pagina die soms traag is, maar wel werkt.
De verkeerde verwachting: een check die status 200 verwacht van een URL die doorverwijst, of zoekt naar tekst die bij een redesign is veranderd.
De verkeerde URL: een pagina achter rate limiting, botbescherming of een login, of een stagingserver die ’s nachts uit staat.
Gepland werk: deployments en onderhoud die een site bewust platleggen.
Verkeerde routering: een melding die technisch klopt, maar naar iemand gaat die er niets mee kan. Voor die persoon is het ruis.
Bevestig elke fout met een tweede check
Dit is de effectiefste oplossing. Mislukt een check, controleer dan eerst opnieuw voordat je iets anders doet. Een verloren pakket of een korte hapering doorstaat de tweede check; een echte storing faalt opnieuw. Alleen een bevestigde fout opent een incident. Zo verdwijnen de meeste haperingen, zonder dat echte meldingen meer dan een paar seconden later komen.
Diensten die vanaf meerdere locaties checken, kunnen de tweede check vanaf een andere plek uitvoeren. Dat vertelt je ook iets nuttigs als de locaties het langere tijd oneens zijn. Faalt je site vanaf het ene continent en werkt hij vanaf het andere, dan ligt het probleem waarschijnlijk bij de routering of een CDN-edge en niet bij je server. Uptimecheck checkt vanuit Stockholm, Londen en New York en bevestigt elke fout vanaf een tweede locatie voordat er een incident opent, zodat één hapering niemand wakker maakt; de pagina over uptime monitoring legt de werkwijze uit. Wil je weten hoe checks tot meldingen leiden, lees dan wat uptime monitoring is.
Stel time-outs in die bij de praktijk passen
Een time-out is de tijd die een check wacht voordat hij de site als down aanmerkt. Stel je hem te krap in, dan wordt normale variatie een storing. Stel je hem te ruim in, dan telt een site die 40 seconden over een antwoord doet als up.
Bekijk de responstijdhistorie van een paar weken. Noteer het normale bereik en de traagste normale responses.
Stel de time-out ruim boven de traagste normale response in, maar onder het punt waarop bezoekers afhaken.
Behandel traagheid als een apart signaal. Een pagina die van 300 ms naar 4 seconden is gegaan, verdient aandacht, maar tijdens werktijd en niet als storingsmelding midden in de nacht.
Zit een pagina regelmatig dicht bij de time-out, dan is de monitor niet het probleem. De pagina is het probleem.
Verwacht de juiste statuscode en inhoud
Veel valse meldingen komen van checks die het verkeerde verwachten:
Redirects. Wie http://northwind.shop monitort terwijl de site doorverwijst naar https://www.northwind.shop/, voegt een extra stap toe die zelf kan falen. Monitor de uiteindelijke URL direct, en wil je de redirect controleren, geef die dan een eigen monitor.
Kwetsbare inhoudschecks. Een check op een marketingkop breekt bij de volgende tekstwijziging. Kies iets stabiels dat alleen verschijnt als de pagina werkt, zoals de bedrijfsnaam in de footer, een element uit het productoverzicht of “status”:”ok” van een health endpoint.
Te ruim. Elke 2xx- of 3xx-code accepteren verbergt echte fouten. Alleen 200 accepteren van een endpoint dat terecht 204 teruggeeft, veroorzaakt valse. Sluit aan bij wat het endpoint echt teruggeeft.
Inhoudsvalidatie vermindert valse en gemiste meldingen tegelijk: een foutpagina van een proxy die 200 teruggeeft, faalt de check, en een cosmetische wijziging niet.
Monitor de juiste URL
Sommige URL’s zijn van nature slechte doelen voor monitoring. Pagina’s achter botbescherming of een web application firewall blokkeren af en toe monitoringverkeer, en dat lijkt op downtime. Pagina’s met strenge rate limiting kunnen na een reeks checks 429 teruggeven. Pagina’s achter een login sturen je door naar het inlogformulier. En de homepage wordt vaak zo zwaar gecachet dat hij up blijft terwijl alles erachter down is.
Een apart health endpoint voorkomt dit allemaal. Het wordt niet gecachet, kost weinig om te serveren, geeft een voorspelbare body terug en faalt alleen als een afhankelijkheid faalt. Zie zo bouw je een health check endpoint. Moet je een pagina achter beveiliging monitoren, laat de monitoringdienst dan door en stuur een herkenbare user agent-header mee, zodat het verkeer makkelijk te herkennen is.
Routeer meldingen per monitor
Een melding is alleen nuttig voor iemand die er iets mee kan. Stuur je elke monitor naar iedereen, dan worden echte meldingen ruis voor de meeste ontvangers. Routeer daarom op impact en eigenaarschap:
Monitor (voorbeeld)KanaalWieCheckout en betaalcallbackPushmelding en teamchatWie er dienst heeftHealth endpoint van de publieke APITeamchat en webhookPlatformteamMarketingsite en blogE-mailWebteam, tijdens werktijdStaging en interne toolsApart chatkanaalDe eigenaar ervan
In Uptimecheck kies je de meldingskanalen per monitor. Meldingen gaan naar e-mail, Slack, Microsoft Teams, Discord, Google Chat, Mattermost, Telegram, PagerDuty, ntfy, Pushover, webhooks en pushmeldingen op je telefoon, op elk abonnement. Zie meldingen en notificaties. Met on-call-roosters bereiken pushmeldingen degene die op dat moment dienst heeft, en escalatie kan een kanaal 5 tot 60 minuten achterhouden en pas waarschuwen als niemand het incident heeft bevestigd. Bureaus kunnen monitors per klantproject groeperen en per monitor de kanalen kiezen, zodat de meldingen van elke klant bij het team komen dat voor die klant zorgt.
Ga slim om met gepland onderhoud
Geplande downtime mag nooit iemand oproepen. Zet vóór een migratie of een lange deployment de monitors die geraakt worden in een onderhoudsvenster. Heeft je tool dat niet, pauzeer ze dan of verplaats hun meldingen tijdelijk naar een rustig kanaal, en maak het hervatten van de monitoring een vaste regel in je deploymentchecklist.
In Uptimecheck kunnen onderhoudsvensters eenmalig of terugkerend zijn. Tijdens een venster zijn er geen meldingen, geen incidenten en geen verlies aan uptime, en het venster staat op je statuspagina en kan naar abonnees worden gemaild.
Laat het ook je klanten weten. Een bericht op je statuspagina vooraf, met het tijdvenster en wat er geraakt wordt, zorgt dat niemand verrast wordt en dat support geen tickets krijgt over iets wat je zelf had gepland. Deployments die elke keer een paar seconden fouten veroorzaken, zijn een ander probleem: los die op met rolling of zero-downtime deploys in plaats van de meldingen te negeren.
Gebruik herstelmeldingen
Een herstelmelding is de melding die zegt dat het voorbij is, met de totale downtime. Het aantal meldingen wordt er niet kleiner door, maar het werk per melding wel. Zonder herstelmelding moet iemand blijven controleren of een korte storing al voorbij is. Met herstelmelding is een hapering van twee minuten ’s nachts één melding en één all-clear die tot de ochtend kunnen wachten. Uptimecheck stuurt na elk incident een herstelmelding.
Bekijk je monitors met de meeste ruis
Zet één keer per maand de monitors op een rij die het vaakst alarm sloegen en stel bij elk ervan deze vragen:
Was elke melding echt? Zo niet, welke instelling veroorzaakte hem: locatie, time-out, verwachting of URL?
Heeft iemand actie ondernomen? Doet nooit iemand dat, pas dan de routering aan of verwijder de monitor.
Is de site zelf instabiel? Veel korte echte storingen zijn geen valse meldingen; ze wijzen op een overbelaste server of een zwakke afhankelijkheid, en drempelwaarden voor servermeldingen helpen je de oorzaak te vinden.
Is de monitor nog nodig? Uitgefaseerde sites en oude stagingservers zijn een veelvoorkomende bron van ruis.
Met wekelijkse en maandelijkse e-mailrapporten die uptime en incidenten samenvatten, is deze review zo gedaan.
Checklist tegen valse meldingen
Bevestig elke fout met een tweede check voordat je alarm slaat.
Baseer time-outs op de echte responstijdhistorie.
Monitor uiteindelijke URL’s, geen redirects, en controleer op stabiele inhoud.
Kies liever health endpoints dan gecachete of beveiligde pagina’s.
Stuur elke monitor naar de mensen die er iets mee kunnen.
Zet gepland werk in een onderhoudsvenster en kondig het aan.
Bekijk elke maand de monitors met de meeste ruis.
Samenvatting
Valse meldingen zijn een configuratieprobleem, en de meeste los je in een middag op. Bevestig elke fout met een tweede check, controleer de juiste URL op het juiste, stuur meldingen alleen naar waar iemand er iets mee kan en blijf evalueren. De beloning is een team dat elke melding leest, omdat elke melding ertoe doet.
Uptimecheck controleert elke fout opnieuw voordat er een melding uitgaat en laat je meldingen per monitor routeren. Start een gratis proefperiode van 14 dagen, zonder creditcard.