Sådan overvåger du leverandørers statussider for nedbrudsvarsler

Lige før midnat stillehavstid den 19. oktober 2025 efterlod en race condition i DNS-automatiseringen bag Amazon DynamoDB tjenestens regionale slutpunkt i us-east-1 med en tom DNS-post. Alt, der afhang af DynamoDB i den region, begyndte at fejle, og nedbruddet spredte sig til andre afhængige AWS-tjenester. Ifølge AWS' egen officielle redegørelse varede hændelsen i cirka fjorten en halv time.

Mange teams havde den morgen fuldstændig velfungerende servere. Deres oppetidsmonitorer forblev grønne, mens deres loginudbyder, betalingsgateway eller e-mailtjeneste kæmpede for livet. De fleste nedbrud er dog mere afdæmpede: Din e-mailudbyder forsinker afsendelser med fyrre minutter, supporten vælter i henvendelser om manglende links til nulstilling af adgangskoder, og til sidst opdager nogen leverandørens statusside, som i en halv time har vist «Forringet ydeevne».

Jeg arbejder hos Page Deltas, et værktøj der overvåger offentlige websider og giver besked, når de ændrer sig på en måde, der betyder noget for dig; hav det i baghovedet, når jeg nedenfor sammenligner med andre løsninger. Dette indlæg gennemgår, hvordan du peger værktøjet mod statussiderne for dine uundværlige leverandører: hvilken URL du vælger, hvordan du skriver en brief, der fjerner støjen, hvor advarslerne skal lande, og hvor grænserne for denne model går.

Hvorfor din interne overvågning forbliver grøn

Din oppetidsmonitor spørger kun, om dit eget websted svarer – og under et nedbrud hos en ekstern leverandør svarer det som regel helt normalt. Dit APM-system vil vise en stigning i fejl på udgående kald til leverandøren, men det kan ikke fortælle dig, om fejlen ligger i din kode eller i deres infrastruktur. Det er præcis det spørgsmål, en statusside besvarer, og svaret afgør dine næste skridt: Du ruller ikke febrilsk den seneste times udgivelse tilbage; du informerer supporten om, at der er tale om et kendt eksternt problem, og du overvejer at opdatere din egen statusside.

Hvorfor så ikke bare tilmelde sig direkte på leverandørens egen side? Det bør du gøre, hvis det dækker dine behov. Mange statussider kører på Atlassian Statuspage og tilbyder advarsler via e-mail, SMS, Slack, Teams eller webhooks, alt efter hvad leverandøren har aktiveret. Problemerne opstår ved den ottende leverandør: Hvert abonnement er en særskilt opsætning, der ofte ender i en enkelt medarbejders indbakke, hver leverandør formaterer beskeder forskelligt, og filtrering til kun de komponenter, du anvender, understøttes sjældent. Nogle leverandører driver endda hjemmelavede statussider helt uden tilmeldingsknap.

En webændringsmonitor giver dig én ensartet arbejdsgang for alle leverandører: Du indsætter URL'en på statussiden, beskriver hvad du interesserer dig for i én sætning, og alle advarsler lander i den samme kanal i samme format.

Hvilke sider bør du overvåge?

Vælg siden, der viser den aktuelle driftsstatus her og nu, typisk status.leverandoer.dk. Vælg ikke leverandørens generelle forside eller en markedsføringsside om pålidelighed. De fleste SaaS-statussider deler samme opbygning: en liste over komponenter med en statusangivelse, et banner for aktive hændelser, planlagte vedligeholdelsesvinduer og en kort oversigt over nylige hændelser med link til det fulde arkiv.

Begynd med de afhængigheder, dine kunder ville mærke med det samme ved et nedbrud. For de fleste softwarevirksomheder er det en overskuelig liste.

Hvis du kun kan overvåge nogle få, så start fra toppen. Fejl i betaling og login bliver til supporthenvendelser på få minutter, mens et sløvt CDN i første omgang måske kun ses i dine interne grafer. De 10 URL'er i gratisabonnementet dækker alle fem rækker og efterlader stadig plads til de ekstra sider nedenfor.

To andre sider er værd at kende til. Historiksiden (ofte /history) er en glimrende sekundær overvågning for en kritisk leverandør: Et kortvarigt nedbrud kan opstå og løses mellem to kontroller af forsiden, men vil fremgå af historikken, så du stadig bliver opmærksom på det. Under et længerevarende nedbrud kan du desuden tilføje den specifikke hændelses URL som en midlertidig monitor for at modtage hver eneste opdatering. Slet den igen, når problemet er løst, så den ikke optager din URL-grænse.

Opsætning trin for trin

Opsætningen tager cirka fem minutter og følger samme princip som vores guide til overvågning af changelogs, blot med en tilpasset brief.

1. Opret en konto og konfigurér en kanal

Opret en gratis konto, åbn Kanaler, og vælg det sted, advarslerne skal lande. Jeg anbefaler en dedikeret kanal som #vendor-status frem for #engineering, hvor beskeder let drukner. Slack, Discord og Microsoft Teams benytter en indgående webhook-URL. I Teams højreklikker du på kanalen, vælger Connectors, derefter Indgående webhook, Konfigurér og indsætter URL'en i Page Deltas. Ved e-mail skal modtageren først bekræfte en verificeringsmail. Klik på Send test på hver kanal for at sikre modtagelsen.

2. Tilføj en monitor med en brief

Klik på Ny monitor, og indsæt statussidens URL. Hold dig til én leverandør pr. monitor, så hver brief kan specificere præcis den leverandørs komponenter. Hvis forskellige teams følger forskellige leverandører, knyttes der blot en særskilt kanal til hver monitor.

Statussider ændrer sig oftere, end man skulle tro, selv på en rolig dag: Oppetidsprocenter svinger en anelse, tidsstempler for «senest opdateret» rykker sig, og listen over nylige hændelser skrider en dag frem med en ny linje med «Ingen hændelser rapporteret». Planlagt vedligeholdelse annonceres uger i forvejen. Et almindeligt diff-værktøj ville reagere på alt dette.

Monitorens beskrivelse er den prompt, vores LLM vurderer for at afgøre, om en ændring er væsentlig. Skriv den som en instruks til en kollega, der holder øje med siden for dig. For en e-mailudbyder fungerer en formulering som denne perfekt:

Statusside for vores e-mailleverandør. Vi bruger udelukkende komponenterne
Email API og Webhooks i regionen US.
Advar mig, når der oprettes en ny hændelse, der påvirker disse komponenter
eller den region, når status eller alvorlighed ændres, eller når den er løst.
Advar mig, hvis en af komponenterne skifter væk fra Operational.
Ignorér oppetidsprocenter, "senest opdateret"-tidsstempler, de daglige
"Ingen hændelser rapporteret"-linjer og hændelser i andre regioner.
Nævn kun planlagt vedligeholdelse, hvis den starter inden for 48 timer.
Opsummer berørt komponent, aktuel status og seneste opdatering.

Udelukkelseslinjen løfter det meste af arbejdet. Udelader du den, vil du bruge den første uge på at modtage advarsler ved midnat, når tabellen med hændelser rykker et døgn frem.

Ved en stor cloududbyder er regions- og servicenavne endnu vigtigere. Et offentligt cloud-dashboard omfatter hundredvis af tjenester på tværs af snesevis af regioner, og på en normal uge er der altid noget et sted, der er forringet. Navngiv udtrykkeligt de regioner og tjenester, din infrastruktur afhænger af, og bed om udelukkende at høre om dem.

3. Lad det første tjek fastlægge udgangspunktet

En ny monitor kører sit første tjek kort efter oprettelsen. Dette tjek gemmer udgangspunktet, så du ikke modtager en falsk advarsel i det første minut, medmindre siden rent faktisk ændrer sig mellem to tjek. Åbn monitoren bagefter, og tjek skærmbilledet for at bekræfte, at den fangede den forventede liste over komponenter.

4. Kør et øjeblikkeligt tjek ved mistanke

Du angiver ikke et fast tjekinterval i Page Deltas. Tidsplanen er adaptiv: Sider med høj aktivitet kontrolleres oftere, og betalte planer har forrang i køen. Da en statusside er stille det meste af tiden, kan du, hvis din fejlrate pludselig stiger og du mistænker en leverandør, klikke på Tjek nu på monitoren. Samme handling er tilgængelig via API, begrænset til én gang i minuttet pr. monitor:

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

Hvad du gør, når en advarsel lander

Når en ændring matcher din brief, modtager du én samlet besked med en opsummering i klart sprog og skærmbilleder af før og efter. Bruger du den signerede webhook, ser dataene således ud (værdierne er fiktive for eksemplets skyld):

{
  "event": "change.detected",
  "monitor_id": "01HX7Q...",
  "monitor_url": "https://status.example-mail.com/",
  "monitor_name": "Status for e-mailudbyder",
  "change_id": "...",
  "detected_at": "2026-10-14T07:21:00Z",
  "summary": "Ny hændelse: forsinket e-maillevering i region US. Email API skiftede fra Operational til Degraded Performance. Status: Under undersøgelse.",
  "before_screenshot_url": "https://.../before.png",
  "after_screenshot_url": "https://.../after.png",
  "dashboard_url": "https://app.pagedeltas.com/monitors/..."
}

Den første person, der ser advarslen, bør svare i tråden med, hvad hændelsen betyder for jeres drift. Supporten kan fastgøre et autosvar om et kendt problem, inden sagerne vælter ind. Vagthavende ingeniør kan indstille fejlfindingen i en nylig kodeudrulning, som ikke er skyld i problemet, og hvis nedbruddet rammer brugerne, kan I opdatere jeres egen statusside, så kunderne hører det fra jer først.

Hvis dit team anvender PagerDuty eller et andet incident-værktøj, kan den signerede webhook videresende dataene via en lille serverless-funktion. Da vores payload ikke har PagerDutys oprindelige format, behøver du kun få linjer kode for at validere signaturen og sende hændelsen videre:

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

Beregn hash-værdien på den rå besked, før du parser den som JSON, da signaturen ellers ikke vil stemme. Vores kanaldokumentation gennemgår detaljerne. Hver advarsel sendes én gang pr. kanal uden automatiske genforsøg: For uundværlige leverandører kan du med fordel tilknytte en sekundær kanal af en anden type (eksempelvis Slack plus e-mail), hvis Slack eller integrationsfunktionen skulle svigte.

Hvor begrænsningerne ligger

Denne opsætning videregiver, hvad en leverandør melder ud offentligt, og det medfører visse naturlige begrænsninger, du bør kende.

Leverandører er ofte langsomme til at offentliggøre hændelser. Dine egne interne fejlgrafer vil undertiden vise problemer, før statussiden anerkender fejlen; betragt derfor advarslen som en bekræftelse snarere end din allerførste varsling. Det erstatter heller ikke syntetiske tests eller oppetidsovervågning af dit eget API: De sidstnævnte fortæller dig, at dit produkt fejler; statussiden forklarer hvorfor.

Mellem tjek opfanges en ændring ved næste planlagte kørsel, uden faste minuttal. For de en eller to leverandører, hvor hvert minut tæller, bør du beholde leverandørens eget direkte abonnement og lade Page Deltas håndtere resten. Desuden overvåger vi kun offentlige sider: En status, der kun er synlig inde i en lukket administrationskonsol, kan vi ikke nå i øjeblikket.

Vi sammenligner teksten på siden. Viser en leverandør kun driftsstatus som en farvet prik uden nogen tilhørende tekstændring, vil vi ikke registrere det. Visualping gør det muligt at overvåge et pixelområde og er bedre egnet i det specifikke tilfælde. Endelig: Hvis selve statussiden går ned, fejler tjekket i stedet for at sende en advarsel, og efter 10 mislykkede tjek i træk pauses monitoren automatisk, mens dine administratorer modtager besked.

Start med tre leverandører

Vælg de tre leverandører, hvis nedbrud ville ramme dig hårdest – typisk betalinger, login og e-mail. Indsæt URL'erne på deres statussider, tilpas ovenstående brief med dine komponenter og regioner, og send en testadvarsel til #vendor-status. Gratisabonnementet dækker 10 URL'er med AI-filtrering, alle advarselskanaler og API-adgang uden krav om betalingskort. Start gratis overvågning.

Julien, produktchef hos Page Deltas