Responstijd monitoring

Waarom verdient de responstijd een eigen alert

Standaard uptime-alerts zijn gebaseerd op een binair signaal: up of down. Het grijze gebied daartussen – up, maar traag – is waar de meeste moderne storingen zich werkelijk afspelen. Een foutief geconfigureerde database-query duurt ineens 4 seconden in plaats van 50ms. Een memory leak veroorzaakt pieken in de garbage collection. Een externe API die door de backend wordt aangeroepen begint te haperen. Geen van deze dingen legt de website volledig plat, maar maakt hem wel onbruikbaar – en het zijn vroege waarschuwingssignalen van een storing die nog een uur of twee verwijderd is.

Monitoring van de responstijd vangt vertragingen op voordat ze uitgroeien tot een storing. Je stelt een drempel per monitor in, en als de responstijd deze meerdere controles op rij overschrijdt, krijg je een alert. Voordat het alert je bereikt, heb je nog wat speling om het probleem te onderzoeken, op te schalen, het problematische verzoek af te remmen, of de deploy terug te draaien die het veroorzaakte.

Hoe drempels werken in DiagnoSEO Uptime Monitoring

Elke monitor kan worden ingesteld met twee parameters: rt_threshold_ms en rt_threshold_breaches. De eerste is de responstijd in milliseconden die je als acceptabel beschouwt. De tweede is het aantal opeenvolgende controles dat deze tijd moet worden overschreden voordat er een alert wordt verstuurd. Standaard staat de drempel uit en is het aantal overschrijdingen drie.

Het design met twee parameters beschermt tegen valse positieven. Netwerkjitter komt voor. Pauzes door garbage collection komen voor. Een enkele piek naar 1 seconde terwijl normaal 200ms is, is niet het waard om iemand om 3 uur 's nachts wakker te maken. Maar drie keer achter elkaar een respons van 1 seconde wel – dat is aanhoudende vertraging, geen incidentele hapering. Kies de drempel op basis van normaal gedrag plus een comfortabele marge: als p95 gewoonlijk 400ms is, kies dan 1000ms als drempel. Is p95 50ms (interne API), neem dan 200ms.

Waarmee het goed samenwerkt

Responstijd-alerts werken het best in combinatie met andere signalen van de monitor. Een compleet beeld: de drempel voor responstijd geeft aan dat het systeem verslechtert; de HTTP-code geeft aan wanneer het werkelijk breekt; SSL/domein-waarschuwingen gaan over tijdgebaseerde incidenten; DNS-wijzigingsalerts over configuratiedrift. Samen vormen deze vier signalen op dezelfde monitor een volledige observability in plaats van het binaire “werkt het”.

Het dashboard helpt hier ook bij. Elke monitor toont een sparkline van de laatste responstijden – een snelle visuele indicator voor patronen van degradatie. De uitgebreide weergave toont gemiddelde responstijden over 24u, 7d en 30d. Zie je het gemiddelde week na week omhoog kruipen, dan is dat een vroeg signaal om te onderzoeken voordat het het alertniveau overschrijdt.

Praktische drempels per paginatype

• Marketinglandingspagina’s: 1500ms is redelijk. Ze zijn zwaar door afbeeldingen en tracking-scripts; absolute snelheid is minder belangrijk dan stabiliteit.
• Product-/categoriepagina’s voor e-commerce: 800-1200ms. Trage e-commerce doodt conversie; strakkere drempels vangen problemen sneller op.
• Applicatie-dashboards: 500-800ms. Gebruikers verwachten directheid. Trage dashboards laten je product defect lijken.
• Publieke API: 200-400ms voor eenvoudige endpoints, meer voor zware berekeningen. Maak hier verschillende tiers.
• Interne microservices health checks: 50-100ms. Ze horen vrijwel direct te reageren; traagheid betekent vrijwel altijd een echt probleem.

Wat je ook kiest, kies niet één keer en vergeet het daarna. Herzie het ieder kwartaal op basis van daadwerkelijke trends. Krijg je constant drempel-alerts die geen echte problemen vertegenwoordigen, dan is de drempel te streng. Krijg je een storing zonder voorafgaand drempelalert, dan was de drempel te ruim.

Alert routing

Alerts voor het overschrijden van drempels gaan via dezelfde kanalen als down/recovery-alerts: Email, Telegram, Slack, Discord, SMS. Ze respecteren dezelfde nachtsilence-instelling. Ze worden gelogd in dezelfde alert-tabel. Het enige verschil is het type gebeurtenis (“threshold” in plaats van “down”) en de inhoud van het bericht – deze vermeldt de actuele responstijd en de ingestelde drempel, zodat je direct ziet met hoeveel deze is overschreden.

Configuratie

Bewerk een willekeurige monitor. Stel in het formulier "Responstijd drempel (ms)" in op het gewenste getal. Pas eventueel “opeenvolgende overschrijdingen” aan als de standaardwaarde 3 niet aansluit bij je tolerantie. Sla op. Vanaf de volgende cyclus vergelijkt elke controle de responstijd met de drempel en krijg je na het ingestelde aantal opeenvolgende overschrijdingen een notificatie.

Veelgestelde vragen

• Welke responstijd-metriek wordt geregistreerd?

  Time To First Byte (TTFB) — milliseconden tussen het verzenden van het verzoek en het ontvangen van de eerste byte van het antwoord. Plus de totale tijd om het volledige antwoord op te halen. TTFB is doorgaans de meest bruikbare, enkele metriek voor de gezondheid van een server.

• Wat is een “goede” responstijd?

  Dat hangt af van locatie en inhoud. Voor een statische pagina met CDN: onder de 100ms is uitstekend, onder 300ms is goed. Voor dynamische apps: onder 500ms is goed, onder 1000ms acceptabel, boven 2000ms is traag. Vergelijk met je eigen historische data in plaats van absolute cijfers.

• Kan ik een alert krijgen als de responstijd de drempel overschrijdt?

  Ja. Iedere monitor heeft een optionele responstijd-drempel. Als 3 opeenvolgende checks de drempel overschrijden, ontvang je een “slow response”-alert. Het vereiste van 3 checks voorkomt valse meldingen door incidenteel netwerkverlies.

• Vanaf waar wordt de responstijd gemeten?

  Vanaf onze 13 geografische checkpoints (Europa, Noord-Amerika, Azië, Zuid-Amerika, Oceanië). Voor een single-region monitor zijn de tijden afkomstig uit de dichtstbijzijnde regio. Bij multi-region wordt iedere regio apart gemeten – handig om regionale CDN-problemen te detecteren.

• Toont het dashboard responstijd-trends?

  Ja – een voortschrijdend 30-dagen gemiddelde, dagelijkse max/min en percentielen (p50, p95). Ze zijn handig voor capaciteitsplanning: als p95 van 800ms naar 1500ms is gestegen in een maand, zijn je servers overbelast, ook als je uptime % nog steeds 100% is.