Så övervakar du leverantörers statussidor för avbrottslarm

Strax före midnatt Stillahavstid den 19 oktober 2025 orsakade ett kapplöpningstillstånd i DNS-automatiseringen bakom Amazon DynamoDB att tjänstens regionala slutpunkt i us-east-1 fick en tom DNS-post. Allt som var beroende av DynamoDB i den regionen började fela, och problemen spred sig till andra beroende AWS-tjänster. Enligt AWS egen sammanfattning pågick incidenten i ungefär fjorton och en halv timme.

Många team hade den morgonen fullt fungerande egna servrar. Deras drifttidsövervakning förblev grön medan deras inloggningsleverantör, betalväxel eller e-posttjänst slogs med haverier. De flesta avbrott är dock mer lågmälda: Din e-postleverantör fördröjer utskick med fyrtio minuter, supporten svämmar över av ärenden om uteblivna lösenordsåterställningar, och till sist hittar någon leverantörens statussida, som i en halvtimme visat «Försämrad prestanda».

Jag arbetar på Page Deltas, ett verktyg som bevakar offentliga webbsidor och larmar när de förändras på ett sätt som berör dig; ha det i bakhuvudet när jag jämför med andra verktyg nedan. Det här inlägget förklarar hur du riktar övervakningen mot statussidorna för dina mest kritiska leverantörer: vilken URL du väljer, hur du skriver en brief som skär bort bruset, vart larmen ska skickas och var gränserna för denna metod går.

Varför din interna övervakning förblir grön

Din drifttidsövervakare kontrollerar bara om din egen webbplats svarar – och under ett avbrott hos en extern leverantör svarar den oftast felfritt. Ditt APM-system kommer att visa en topp i felaktiga anrop mot leverantören, men kan inte avgöra om felet ligger i din egen kod eller i deras infrastruktur. Det är just den frågan en statussida besvarar, och svaret styr dina nästa åtgärder: Du rullar inte i panik tillbaka driftsättningen från en timme tidigare; du meddelar supporten att det rör sig om en känd extern incident och överväger att uppdatera din egen statussida.

Varför inte bara prenumerera direkt på leverantörens sida? Det bör du göra om det tillgodoser dina behov. Många statussidor drivs via Atlassian Statuspage och erbjuder aviseringar via e-post, SMS, Slack, Teams eller webhooks, beroende på vad leverantören aktiverat. Problemen hopar sig vid den åttonde leverantören: Varje prenumeration är en separat installation som ofta hamnar i inkorgen hos en enskild medarbetare, alla leverantörer formaterar sina meddelanden olika, och att filtrera på enbart de komponenter du använder erbjuds sällan. Vissa leverantörer har till och med egenbyggda sidor helt utan prenumerationsknapp.

En webbförändringsövervakare ger dig ett enhetligt tillvägagångssätt för alla leverantörer: Du klistrar in URL:en till statussidan, beskriver vad du bryr dig om i en mening, och alla larm anländer till samma kanal i samma format.

Vilka sidor bör du bevaka?

Välj sidan som visar aktuell driftstatus i realtid, oftast status.leverantor.se. Välj inte leverantörens allmänna startsida eller en marknadsföringssida om tillförlitlighet. De flesta SaaS-statussidor delar samma struktur: en lista över komponenter med statusangivelser, en banner för pågående incidenter, schemalagt underhåll och en kort historik över nyligen inträffade händelser med länk till hela arkivet.

Börja med de beroenden vars bortfall dina kunder skulle märka direkt. För de flesta mjukvaruteam är den listan kort.

Om du bara kan övervaka ett fåtal, börja uppifrån. Avbrott i betalningar och inloggning blir till supportärenden på några minuter, medan en seg CDN-nod inledningsvis kanske bara syns i dina tekniska grafer. De 10 URL:erna i gratisplanen täcker samtliga fem rader och lämnar ändå utrymme för tilläggen nedan.

Två andra sidor är värdefulla att känna till. Historiksidan (ofta /history) är en utmärkt sekundär övervakning för en affärskritisk leverantör: Ett kort avbrott kan starta och åtgärdas mellan två kontroller av huvudsidan, men förblir synligt i historiken så att du får kännedom om det i efterhand. Vid en utdragen incident kan du även lägga till den specifika incidentsidans URL som en tillfällig övervakare för att följa varje uppdatering. Ta bort den när problemet är löst så att den inte belastar ditt URL-tak.

Konfiguration steg för steg

Installationen tar ungefär fem minuter och följer samma mönster som vår guide för övervakning av ändringsloggar, fast med en anpassad brief.

1. Skapa konto och konfigurera en kanal

Registrera ett gratis konto, öppna Kanaler och ställ in var larmen ska hamna. Jag rekommenderar en separat kanal som #vendor-status i stället för #engineering, där meddelanden lätt drunknar. Slack, Discord och Microsoft Teams tar emot en inkommande webhook-URL. I Teams högerklickar du på kanalen, väljer Anslutningsappar, sedan Inkommande webhook, Konfigurera och klistrar in URL:en i Page Deltas. För e-post måste mottagaren först bekräfta ett verifieringsmail. Klicka på Skicka test i varje kanal för att säkerställa mottagningen.

2. Lägg till en övervakare med en brief

Klicka på Ny övervakare och klistra in statussidans URL. Håll dig till en leverantör per övervakare så att varje brief kan specificera exakt den leverantörens komponenter. Om olika team bevakar olika leverantörer kopplar du helt enkelt en separat kanal till varje övervakare.

Statussidor förändras oftare än man tror, även under lugna dagar: Drifttidsprocenter skiftar lätt, tidsstämplar för «senast uppdaterad» tickar framåt, och listan över nyligen inträffade händelser flyttas ett dygn med en ny rad för «Inga incidenter rapporterade». Planerat underhåll annonseras veckor i förväg. Ett simpelt diff-verktyg skulle larma på allt detta.

Övervakarens beskrivning är den prompt som vår LLM granskar för att avgöra om en förändring är relevant. Formulera den som en instruktion till en kollega som håller koll på sidan åt dig. För en e-postleverantör fungerar en sådan här skrivning optimalt:

Statussida för vår e-postleverantör. Vi använder enbart komponenterna
Email API och Webhooks i regionen US.
Larma mig när en ny incident publiceras som påverkar dessa komponenter
eller den regionen, när status eller allvarlighetsgrad ändras, eller när den är löst.
Larma mig om någon av komponenterna lämnar läget Operational.
Ignorera drifttidsprocent, tidsstämplar för "senast uppdaterad", dagliga rader
med "Inga incidenter rapporterade" och incidenter i andra regioner.
Nämn planerat underhåll endast om det påbörjas inom 48 timmar.
Sammanfatta berörd komponent, aktuell status och den senaste uppdateringen.

Undantagsraden gör det tunga arbetet. Utelämnar du den kommer du att tillbringa din första vecka med att få nattliga larm vid tolvslaget när incidenttabellen rullar fram ett dygn.

För en stor molnleverantör är regions- och tjänstenamn ännu viktigare. En publik molninstrumentpanel rymmer hundratals tjänster över tiotals regioner, och under en vanlig vecka är det nästan alltid något som är nedsatt någonstans. Namnge uttryckligen de regioner och tjänster din infrastruktur använder, och be om att enbart få larm om dessa.

3. Låt första kontrollen sätta utgångsläget

En nyskapad övervakare kör sin första kontroll strax efter att den skapats. Den kontrollen sparar startläget, så du får inget falsklarm första minuten såvida inte sidan ändras mellan två kontroller. Öppna övervakaren efteråt och granska skärmdumpen för att säkerställa att den fångade rätt lista över komponenter.

4. Kontrollera omedelbart vid misstanke

I Page Deltas ställer du inte in ett fast kontrollintervall. Schemat är adaptivt: Sidor med frekventa ändringar kontrolleras oftare, och betalda planer prioriteras i kön. Eftersom en statussida oftast är tyst kan du, om din felkvot stiger och du misstänker en leverantör, klicka på Kontrollera nu på övervakaren. Samma åtgärd finns tillgänglig via API:et, begränsad till en gång per minut per övervakare:

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

Vad du gör när ett larm anländer

När en ändring matchar din brief får du ett samlat meddelande med en sammanfattning på begripligt språk samt skärmdumpar före och efter. Använder du den signerade webhooken ser innehållet ut så här (värdena är fiktiva för exemplet):

{
  "event": "change.detected",
  "monitor_id": "01HX7Q...",
  "monitor_url": "https://status.example-mail.com/",
  "monitor_name": "Status e-postleverantör",
  "change_id": "...",
  "detected_at": "2026-10-14T07:21:00Z",
  "summary": "Ny incident: fördröjd e-postleverans i region US. Email API ändrades från Operational till 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örsta som ser larmet bör svara i tråden med vad detta innebär för er tjänst. Supporten kan nåla fast ett standardsvar om ett känt fel innan ärendena hinner rasa in. Den jourhavande ingenjören kan avbryta felsökningen av en nyligen driftsatt release som inte bär skulden, och om avbrottet drabbar kunderna uppdaterar ni er egen statussida så att de nås av informationen från er först.

Om ditt team arbetar i PagerDuty eller ett annat incidentverktyg kan den signerade webhooken skicka vidare händelsen via en enkel serverlös funktion. Eftersom vårt format inte är PagerDutys interna format krävs bara några få rader kod för att verifiera signaturen och skicka eventet vidare:

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

Beräkna hash-värdet på råtexten innan du tolkar den som JSON, annars kommer signaturen inte att matcha. Vår kanaldokumentation går igenom alla detaljer. Varje larm skickas en gång per kanal utan automatiska omtag: För oersättliga leverantörer bör du koppla en andra kanal av en annan typ (till exempel Slack plus e-post) ifall Slack eller reläfunktionen skulle drabbas av driftstörningar.

Begränsningar att känna till

Den här lösningen återger vad leverantören officiellt kommunicerar, vilket medför några tydliga begränsningar du bör vara medveten om.

Leverantörer är ofta långsamma med att bekräfta problem offentligt. Dina egna felgrafer visar ibland avvikelser innan statussidan erkänner något; betrakta därför larmet som en bekräftelse snarare än din allra första förvarning. Det ersätter inte heller syntetiska tester eller drifttidsbevakning av ditt eget API: De sistnämnda talar om att din produkt inte fungerar; statussidan förklarar varför.

Mellan kontrollerna fångas en ändring upp vid nästa schemalagda körning, utan garanterat fast intervall. För de en eller två leverantörer där varje minut är dyrbar behåller du även leverantörens eget abonnemang och använder Page Deltas för resten. Vi läser dessutom uteslutande publika sidor: En status som enbart visas inuti en skyddad administratörspanel förblir onåbar tills vidare.

Vi jämför textinnehållet på sidan. Om en leverantör visar status uteslutande med en färgad prick utan att ändra några ord, upptäcker vi det inte. Visualping tillåter övervakning av ett pixelområde och passar bättre i det enskilda fallet. Slutligen: Om själva statussidan kraschar misslyckas kontrollerna i stället för att larma, och efter 10 misslyckade kontroller i rad pausas övervakaren automatiskt samtidigt som dina administratörer meddelas.

Börja med tre leverantörer

Välj de tre leverantörer vars bortfall skulle skada er verksamhet mest – oftast betalningar, inloggning och e-post. Klistra in deras statussidors URL:er, anpassa briefen ovan med era komponenter och regioner, och skicka ett testlarm till #vendor-status. Gratisplanen täcker 10 URL:er med AI-filtrering, samtliga larmkanaler och API-åtkomst, helt utan kreditkort. Börja övervaka gratis.

Julien, produktchef på Page Deltas