Statuspagina's van leveranciers monitoren voor storingsmeldingen

Vlak voor middernacht Pacifische tijd op 19 oktober 2025 zorgde een race condition in de DNS-automatisering van Amazon DynamoDB ervoor dat het regionale eindpunt in us-east-1 een leeg DNS-record kreeg. Alle systemen die in die regio afhankelijk waren van DynamoDB begonnen te haperen, en de uitval breidde zich uit naar andere AWS-diensten die erop steunden. Volgens het officiële overzicht van AWS duurde het incident zo'n veertien en een half uur.

Veel teams beschikten die ochtend over kerngezonde servers. Hun uptime-monitors bleven keurig groen terwijl hun inlogprovider, betalingsverwerker of e-maildienst in zwaar weer verkeerden. De meeste storingen zijn echter subtieler: uw e-mailprovider vertraagt verzendingen met veertig minuten, de helpdesk wordt overspoeld met tickets over niet-aangekomen wachtwoordresets, en uiteindelijk stuit iemand op de statuspagina van de leverancier, die al een halfuur «Verminderde prestaties» vermeldt.

Ik werk bij Page Deltas, een tool die openbare webpagina's monitort en waarschuwt zodra deze veranderen volgens uw criteria; houd dat in gedachten bij de vergelijkingen hieronder. Dit artikel beschrijft hoe u de tool richt op de statuspagina's van cruciale leveranciers: welke URL u kiest, hoe u een instructie (brief) schrijft die ruis wegfiltert, waar u meldingen ontvangt en waar de grenzen van deze opzet liggen.

Waarom uw eigen monitoring groen blijft

Uw uptime-monitor vraagt uitsluitend of uw eigen site reageert – en tijdens een storing bij een externe leverancier doet die dat doorgaans probleemloos. Uw APM zal een piek in fouten registreren op uitgaande calls naar die partij, maar kan u niet vertellen of het probleem in uw code of in hun infrastructuur zit. Dat is precies de vraag die een statuspagina beantwoordt, en dat antwoord stuurt uw vervolgacties: u draait niet gehaast de release van een uur geleden terug; u meldt support dat het om een bekende externe storing gaat en overweegt uw eigen statuspagina bij te werken.

Waarom abonneert u zich niet direct op de pagina van de leverancier? Dat moet u zeker doen als het volstaat. Veel statuspagina's draaien op Atlassian Statuspage en bieden meldingen via e-mail, sms, Slack, Teams of webhooks, afhankelijk van wat de leverancier heeft ingeschakeld. De knelpunten ontstaan bij de achtste leverancier: elk abonnement is een losse configuratie die vaak in de inbox van één persoon belandt, elke partij formatteert berichten anders, en filteren op uitsluitend de componenten die u gebruikt is lang niet altijd mogelijk. Sommige leveranciers beheren zelfs een eigen pagina zonder enige abonneerknop.

Een web-wijzigingsmonitor biedt een eenduidige werkwijze voor elke leverancier: u plakt de URL van de statuspagina, beschrijft in één zin wat relevant is, en elke melding verschijnt in hetzelfde kanaal met een identieke opbouw.

Welke pagina's moet u in de gaten houden?

Kies de pagina die de actuele status toont, meestal status.leverancier.com. Kies niet de algemene homepage of een marketingpagina over betrouwbaarheid. De meeste SaaS-statuspagina's hanteren dezelfde indeling: een overzicht van componenten met een statusaanduiding, een banner voor actieve incidenten, gepland onderhoud en een kort overzicht van recente incidenten met link naar het volledige archief.

Begin met de afhankelijkheden waarvan uw klanten een storing direct zouden merken. Voor de meeste softwareteams is dat een overzichtelijke lijst.

Als u slechts enkele URL's kunt bewaken, begin dan bovenaan. Fouten bij betalingen of authenticatie leiden binnen enkele minuten tot supporttickets, terwijl een trage CDN aanvankelijk misschien alleen in interne grafieken zichtbaar is. De 10 URL's van het gratis abonnement dekken deze vijf rijen ruim af en laten ruimte voor de aanvullingen hieronder.

Twee andere pagina's zijn waardevol. De geschiedenispagina (vaak /history) is een uitstekende tweede monitor voor een kritieke leverancier: een korte storing kan ontstaan en opgelost worden tussen twee controles van de hoofdpagina door, maar blijft in de historie staan – zo bent u er alsnog van op de hoogte. Tijdens een langdurig incident kunt u ook de specifieke incidentpagina als tijdelijke monitor toevoegen om elke update direct te volgen. Verwijder deze zodra het incident is afgerond om uw URL-limiet niet te belasten.

Stapsgewijze configuratie

De configuratie kost ongeveer vijf minuten en volgt hetzelfde stramien als onze handleiding voor changelog-monitoring, met een aangepaste instructie.

1. Account aanmaken en kanaal instellen

Registreer u gratis, ga naar Kanalen en voeg de gewenste bestemming voor meldingen toe. Ik raad een specifiek kanaal aan zoals #vendor-status in plaats van #engineering, waar berichten snel ondersneeuwen. Slack, Discord en Microsoft Teams werken met een inkomende webhook-URL. In Teams klikt u met de rechtermuisknop op het kanaal, kiest u Connectors, vervolgens Binnenkomende webhook, Configureren en plakt u de URL in Page Deltas. Voor e-mail dient de ontvanger eerst een verificatiebericht te bevestigen. Klik op Test versturen bij elk kanaal om de ontvangst te verifiëren.

2. Monitor toevoegen met een instructie (brief)

Klik op Nieuwe monitor en plak de URL van de statuspagina. Houd één leverancier per monitor aan zodat de instructie exact diens specifieke componenten kan benoemen. Als verschillende teams verschillende leveranciers volgen, koppelt u aan elke monitor een apart kanaal.

Statuspagina's veranderen vaker dan u denkt, zelfs op rustige dagen: uptime-percentages schommelen licht, tijdstempels van de «laatste update» verspringen en het overzicht van recente incidenten schuift dagelijks op met een nieuwe regel «Geen incidenten gemeld». Gepland onderhoud wordt weken van tevoren aangekondigd. Een eenvoudige diff-tool zou op al deze details reageren.

De beschrijving van de monitor is de prompt die ons LLM leest om te bepalen of een verandering relevant is. Schrijf deze zoals u instructies aan een collega zou geven die de pagina voor u bijhoudt. Voor een e-mailprovider werkt dit uitstekend:

Statuspagina van onze e-mailprovider. We gebruiken alleen de componenten
Email API en Webhooks in de regio US.
Waarschuw me als er een nieuw incident wordt geplaatst dat invloed heeft op die
componenten of die regio, als de status of ernst wijzigt, of als het is opgelost.
Waarschuw me als een van beide componenten niet meer op Operational staat.
Negeer uptime-percentages, tijdstempels van "laatst bijgewerkt", de dagelijkse
"Geen incidenten gemeld"-regels en incidenten in andere regio's.
Vermeld gepland onderhoud alleen als het binnen 48 uur van start gaat.
Vat de getroffen component, de huidige status en de laatste update samen.

De uitsluitingsregel doet het meeste werk. Als u die weglaat, ontvangt u de eerste week elke nacht om twaalf uur meldingen over het opschuiven van de incidententabel.

Bij een grote cloudprovider zijn regio- en servicenamen nog belangrijker. Een openbaar clouddashboard bevat honderden diensten verspreid over tientallen regio's, en in een normale week hapert er ergens wel iets. Noem expliciet de regio's en services waarop uw infrastructuur draait en vraag alleen om meldingen over die onderdelen.

3. Eerste controle als ijkpunt gebruiken

Een nieuwe monitor voert kort na aanmaak zijn eerste controle uit. Die controle slaat het startpunt op, waardoor u in de eerste minuut geen valse melding krijgt tenzij de pagina tussen twee metingen verandert. Open de monitor nadien en controleer het screenshot om er zeker van te zijn dat de beoogde componentenlijst goed in beeld is.

4. Direct controleren bij vermoedens

In Page Deltas stelt u geen vast controle-interval in. De planning is adaptief: pagina's met veel dynamiek worden vaker gecontroleerd en betaalde abonnementen krijgen voorrang bij pieken in de wachtrij. Een statuspagina is meestal rustig; stijgt uw foutenpercentage en vermoedt u een externe oorzaak, klik dan op Nu controleren bij de betreffende monitor. Dezelfde actie is beschikbaar via de API, begrensd op eenmaal per minuut per monitor:

curl -X POST \
  -H "Authorization: Bearer $PAGEDELTAS_TOKEN" \
  https://api.pagedeltas.com/api/monitors/$MONITOR_ID/check-now

Wat te doen bij een melding

Komt een verandering overeen met uw instructie, dan ontvangt u één bericht met een samenvatting in duidelijke taal en screenshots van voor en na. Gebruikt u de ondertekende webhook, dan ziet de payload er als volgt uit (waarden zijn fictief voor dit voorbeeld):

{
  "event": "change.detected",
  "monitor_id": "01HX7Q...",
  "monitor_url": "https://status.example-mail.com/",
  "monitor_name": "Status e-mailprovider",
  "change_id": "...",
  "detected_at": "2026-10-14T07:21:00Z",
  "summary": "Nieuw incident: vertraagde e-mailverzending in regio US. Email API gewijzigd van Operational naar Degraded Performance. Status: In onderzoek.",
  "before_screenshot_url": "https://.../before.png",
  "after_screenshot_url": "https://.../after.png",
  "dashboard_url": "https://app.pagedeltas.com/monitors/..."
}

De eerste collega die de melding ziet, kan het beste direct in de thread toelichten wat dit voor uw dienst betekent. Support kan een standaardreactie over een bekende storing klaarzetten voordat de tickets binnenstromen. De ingenieur met piketdienst kan stoppen met het doorspitten van een recente release die niets met de fouten te maken heeft, en als de storing gebruikers raakt, werkt u uw eigen statuspagina bij zodat klanten het nieuws eerst van u horen.

Werkt uw team met PagerDuty of een ander incidentplatform, dan kan de ondertekende webhook dit voeden via een kleine serverless relay. Aangezien onze payload afwijkt van het PagerDuty-formaat, volstaan enkele regels code om de handtekening te verifiëren en de melding door te sturen:

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;
}

Bereken de hash over de onbewerkte ruwe body voordat u deze als JSON parset, anders klopt de handtekening niet. De kanalen-documentatie licht alle details toe. Elke melding wordt één keer per kanaal verzonden zonder automatische herhaalpoging: voor bedrijfskritische leveranciers stelt u het beste een tweede kanaal van een ander type in (bijvoorbeeld Slack én e-mail) voor het geval Slack of de relay-functie hapert.

Beperkingen om rekening mee te houden

Deze opzet rapporteert wat een leverancier openbaar communiceert, en dat kent enkele duidelijke beperkingen waar u zich bewust van moet zijn.

Leveranciers wachten vaak met het publiceren van incidenten. Uw eigen foutgrafieken tonen soms al problemen voordat de externe statuspagina iets meldt: zie de waarschuwing daarom als bevestiging en niet altijd als eerste alarmsignaal. Het is bovendien geen vervanging voor synthetische tests of de uptime-monitoring van uw eigen API. Die vertellen u dat uw dienst hapert; de statuspagina legt uit waarom.

Tussen controles door wordt een wijziging bij de volgende geplande ronde opgepikt, zonder vast interval. Voor die ene of twee leveranciers waar elke minuut telt, behoudt u tevens het abonnement van de leverancier zelf en gebruikt u Page Deltas voor de overige partijen. Daarnaast scannen we alleen openbare pagina's: een status die alleen achter een beheerconsole zichtbaar is, blijft vooralsnog buiten bereik.

We vergelijken de tekst van de pagina. Toont een leverancier een storing alleen via een gekleurd bolletje zonder tekstuele verandering, dan zien we dat niet. Visualping maakt het mogelijk om een pixelgebied te bewaken en sluit beter aan op dat specifieke geval. Tot slot: als de statuspagina zelf uit de lucht gaat, mislukken de controles in plaats van een melding te genereren; na 10 mislukte pogingen op rij pauzeert de monitor automatisch en ontvangen uw beheerders bericht.

Begin met drie leveranciers

Selecteer de drie leveranciers waarvan uitval u de meeste schade zou toebrengen – meestal betalingen, authenticatie en e-mail. Plak de URL's van hun statuspagina's, stem de bovenstaande instructie af op uw componenten en regio's, en verstuur een testmelding naar #vendor-status. Het gratis abonnement omvat 10 URL's met AI-filtering, alle waarschuwingskanalen en API-toegang, zonder creditcardvereiste. Gratis beginnen met monitoren.

Julien, Product Manager bij Page Deltas