Slik overvåker du leverandørers statussider for nedetidsvarsler

Like før midnatt stillehavstid den 19. oktober 2025 førte en kappløpsituasjon i DNS-automatiseringen bak Amazon DynamoDB til at tjenestens regionale endepunkt i us-east-1 fikk en tom DNS-oppføring. Alt som krevde DynamoDB i den regionen begynte å feile, og problemene spredte seg til andre avhengige AWS-tjenester. Ifølge AWS' eget sammendrag varte hendelsen i omtrent fjorten og en halv time.

Mange team hadde den morgenen servere i perfekt stand. Oppetidsovervåkingen forble grønn mens innloggingsleverandøren, betalingsformidleren eller e-posttjenesten slet tungt. De fleste hendelser er imidlertid mindre dramatiske: E-postleverandøren forsinker utsendelser med førti minutter, brukerstøtte oversvømmes av henvendelser om passordtilbakestillinger som aldri kommer, og omsider finner noen leverandørens statusside, som i en halvtime har varslet «Redusert ytelse».

Jeg jobber i Page Deltas, et verktøy som overvåker offentlige nettsider og varsler når de endrer seg i tråd med det du bryr deg om; ha det i bakhodet når jeg sammenligner med andre verktøy nedenfor. Dette innlegget forklarer hvordan du retter overvåkingen mot statussidene til leverandørene du er avhengig av: hvilken URL du velger, hvordan du skriver en brief som fjerner unødvendig støy, hvor varslene skal sendes, og hvor grensene for dette oppsettet går.

Hvorfor din interne overvåking forblir grønn

Oppetidsmonitoren din sjekker bare om ditt eget nettsted svarer – og under et brudd hos en ekstern leverandør svarer det som regel helt fint. APM-verktøyet ditt vil vise en topp i feil på utgående kall til leverandøren, men kan ikke fortelle deg om feilen ligger i din egen kode eller i deres tjeneste. Det er nettopp dette spørsmålet en statusside besvarer, og svaret endrer dine neste handlinger: Du ruller ikke febrilsk tilbake utrullingen fra en time siden; du gir brukerstøtte beskjed om at det er et kjent eksternt problem, og vurderer å oppdatere din egen statusside.

Hvorfor ikke bare abonnere direkte på leverandørens side? Det bør du gjøre dersom det dekker behovet. Mange statussider kjører på Atlassian Statuspage og tilbyr varsler via e-post, SMS, Slack, Teams eller webhooks, avhengig av hva leverandøren har aktivert. Utfordringene melder seg ved den åttende leverandøren: Hvert abonnement er et separat oppsett som ofte ender i innboksen til én enkelt person, alle leverandører formaterer meldingene ulikt, og filtrering ned til kun komponentene du faktisk bruker tilbys sjelden. Enkelte leverandører har til og med hjemmesnekrede sider helt uten abonneringsknapp.

En endringsovervåker gir deg én felles metode for alle leverandører: Du limer inn URL-en til statussiden, beskriver det du bryr deg om i én setning, og hvert varsel ankommer i samme kanal med samme oppbygning.

Hvilke sider bør du overvåke?

Velg siden som viser gjeldende driftsstatus i sanntid, vanligvis status.leverandor.no. Ikke velg leverandørens vanlige forside eller en markedsføringsside om pålitelighet. De fleste SaaS-statussider følger samme oppbygning: en liste over komponenter med en statusangivelse, et banner for aktive hendelser, kommende planlagt vedlikehold og en kort historikk over nylige hendelser med lenke til det fullstendige arkivet.

Start med avhengighetene kundene dine ville merket umiddelbart ved nedetid. For de fleste programvareteam er listen overskuelig.

Hvis du bare kan overvåke noen få, begynn øverst. Feil i betaling og innlogging blir til henvendelser i brukerstøtte på få minutter, mens et tregt CDN innledningsvis kanskje bare oppdages i målingene dine. De 10 URL-ene i gratisabonnementet dekker alle fem radene og gir fortsatt rom for tilleggene nedenfor.

To andre sider er kjekke å kjenne til. Historikksiden (ofte /history) er en god sekundær overvåking for en kritisk leverandør: En kort hendelse kan oppstå og løses mellom to kontroller av hovedsiden, men vil stå oppført i historikken slik at du får vite om den likevel. Under en langvarig hendelse kan du også legge til den spesifikke hendelsessiden som en midlertidig monitor for å motta hver oppdatering. Slett den når hendelsen er løst, slik at den ikke opptar URL-kvoten din.

Oppsett trinn for trinn

Oppsettet tar rundt fem minutter og følger samme flyt som vår guide for overvåking av endringslogger, med en tilpasset brief.

1. Opprett en konto og konfigurer en kanal

Registrer deg gratis, åpne Kanaler og legg til stedet der varslene skal leveres. Jeg anbefaler en dedikert kanal som #vendor-status fremfor #engineering, der meldingene lett drukner. Slack, Discord og Microsoft Teams tar imot en innkommende webhook-URL. I Teams høyreklikker du på kanalen, velger Koblinger, deretter Innkommende webhook, Konfigurer og limer inn URL-en i Page Deltas. For e-post må mottakeren først godkjenne en bekreftelsesmelding. Klikk på Send test på hver kanal for å verifisere mottaket.

2. Legg til en monitor med en brief

Klikk på Ny monitor og lim inn statussidens URL. Hold deg til én leverandør per monitor slik at hver brief kan navngi de nøyaktige komponentene til den leverandøren. Hvis ulike team har ansvar for forskjellige tjenester, kobler du en egen kanal til hver monitor.

Statussider endrer seg oftere enn man forestiller seg, selv på rolige dager: Oppetidsprosenter svinger svakt, tidsstempler for «sist oppdatert» flytter seg, og listen over nylige hendelser forskyves ett døgn med en ny linje med «Ingen hendelser rapportert». Planlagt vedlikehold kunngjøres uker i forkant. Et enkelt diff-verktøy ville utløst varsel på alt dette.

Beskrivelsen av monitoren er instruksen (prompten) som vår LLM analyserer for å vurdere om en endring er av betydning. Formuler den som en instruks til en kollega som passer på siden for deg. For en e-postleverandør fungerer en tekst som dette utmerket:

Statusside for vår e-postleverandør. Vi bruker utelukkende komponentene
Email API og Webhooks i regionen US.
Varsle meg når det publiseres en ny hendelse som påvirker disse komponentene
eller den regionen, når status eller alvorlighetsgrad endres, eller når den er løst.
Varsle meg dersom en av komponentene endrer status fra Operational.
Ignorer oppetidsprosenter, tidsstempler for "sist oppdatert", de daglige
"Ingen hendelser rapportert"-linjene og hendelser i andre regioner.
Nevn planlagt vedlikehold kun dersom det starter innen 48 timer.
Oppsummer berørt komponent, nåværende status og siste oppdatering.

Uteglingslinjen gjør brorparten av jobben. Utelater du den, vil du bruke den første uken på å få nattlige varsler ved midnatt idet hendelsestabellen forskyver seg et døgn.

For en stor skyoperatør er nøyaktige region- og tjenestenavn enda mer avgjørende. Et offentlig sky-dashboard favner hundrevis av tjenester fordelt på titalls regioner, og i en vanlig uke er det nesten alltid et eller annet som er redusert et sted. Navngi spesifikt regionene og tjenestene du kjører på, og be om utelukkende å bli varslet om disse.

3. La den første sjekken etablere utgangspunktet

En nyopprettet monitor kjører sin første kontroll like etter opprettelse. Denne kontrollen lagrer starttilstanden, så du vil ikke få noe feilvarsel i det første minuttet med mindre siden faktisk endrer seg mellom to målinger. Åpne monitoren etterpå og undersøk skjermbildet for å bekrefte at den fanget listen over komponenter du forventet.

4. Sjekk umiddelbart ved mistanke

I Page Deltas setter du ikke et fast kontrollintervall. Tidsplanen er adaptiv: Sider med hyppige endringer sjekkes oftere, og betalte planer har forrang i køen. Siden en statusside som oftest er stille, kan du, hvis feilraten øker og du mistenker en leverandør, trykke på Sjekk nå på monitoren. Samme handling er tilgjengelig via API, begrenset til én gang i minuttet per monitor:

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

Hva du gjør når et varsel mottas

Når en endring matcher din brief, mottar du én samlet melding med et sammendrag i klart språk og skjermbilder av før og etter. Dersom du bruker den signerte webhooken, ser datapakken slik ut (verdiene er oppdiktet for eksempelets skyld):

{
  "event": "change.detected",
  "monitor_id": "01HX7Q...",
  "monitor_url": "https://status.example-mail.com/",
  "monitor_name": "Status e-postleverandør",
  "change_id": "...",
  "detected_at": "2026-10-14T07:21:00Z",
  "summary": "Ny hendelse: forsinket e-postlevering i region US. Email API endret fra Operational til Degraded Performance. Status: Undersøker.",
  "before_screenshot_url": "https://.../before.png",
  "after_screenshot_url": "https://.../after.png",
  "dashboard_url": "https://app.pagedeltas.com/monitors/..."
}

Den første personen som oppdager varselet, bør svare i tråden med hva dette innebærer for egen drift. Brukerstøtte kan feste et svar om et kjent eksternt problem før sakene hoper seg opp. Den vakthavende ingeniøren kan avblåse granskingen av en nylig utrulling som ikke har skylden, og dersom nedetiden rammer sluttbrukerne, oppdaterer du din egen statusside slik at kundene får beskjeden fra deg først.

Dersom teamet ditt benytter PagerDuty eller et annet hendelsesverktøy, kan den signerte webhooken videresende dataene via en enkel serverløs funksjon. Siden vårt format avviker fra PagerDutys opprinnelige format, kreves det bare noen linjer kode for å validere signaturen og sende hendelsen 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-verdien på råteksten før du parser den som JSON, ellers vil ikke signaturen stemme. Vår kanaldokumentasjon dekker alle detaljer. Hvert varsel sendes ut én gang per kanal uten automatiske nye forsøk: For uunnværlige leverandører bør du knytte til en sekundær kanal av en annen type (for eksempel Slack pluss e-post) i tilfelle Slack eller integrasjonsfunksjonen skulle oppleve midlertidig svikt.

Begrensninger du må kjenne til

Dette oppsettet gjengir hva leverandøren melder offisielt, og det medfører enkelte begrensninger det er viktig å være klar over.

Leverandører bruker ofte tid på å innrømme feil. Dine egne feilgrafer vil ofte vise avvik før statussiden innrømmer noe som helst; betrakt derfor varselet som en bekreftelse fremfor ditt aller første varsku. Det er heller ingen erstatning for syntetiske tester eller oppetidsovervåking av ditt eget API: De sistnevnte forteller deg at produktet ditt svikter; statussiden forteller deg hvorfor.

Mellom kontroller oppdages en endring ved neste planlagte kjøring, uten noe garantert fast intervall. For de én eller to leverandørene der hvert minutt er avgjørende, beholder du leverandørens eget abonnement i tillegg og lar Page Deltas ta seg av resten. Vi leser dessuten utelukkende offentlige sider: En status som bare er synlig inne i en lukket administrasjonskonsoll forblir inntil videre utilgjengelig.

Vi sammenligner teksten på siden. Viser en leverandør status kun som en farget sirkel uten at noen ord endres, vil vi ikke registrere det. Visualping lar deg overvåke et pikselområde og er bedre tilpasset det spesifikke scenarioet. Til slutt: Hvis selve statussiden går ned, feiler kontrollene i stedet for å utløse varsel, og etter 10 feilende kontroller på rad pauses monitoren automatisk samtidig som administratorene dine får beskjed.

Start med tre leverandører

Velg ut de tre leverandørene der et nedbruddsavbrudd ville rammet hardest – vanligvis betalinger, innlogging og e-post. Lim inn URL-ene til statussidene deres, tilpass briefen over med komponentene og regionene du bruker, og send et testvarsel til #vendor-status. Gratisabonnementet dekker 10 URL-er med AI-filtrering, samtlige varslingskanaler og API-tilgang, helt uten krav om kredittkort. Start overvåking gratis.

Julien, produktsjef i Page Deltas