Hieman ennen puoltayötä Tyynenmeren aikaa 19. lokakuuta 2025 Amazon DynamoDB:n DNS-automaation kilpatilanne jätti palvelun alueellisen päätepisteen us-east-1-alueella tyhjäksi DNS-tietueeksi. Kaikki kyseisellä alueella DynamoDB:tä tarvitsevat järjestelmät alkoivat kaatua, ja häiriö laajeni muihin siitä riippuvaisiin AWS-palveluihin. AWS:n oman yhteenvedon mukaan katkos kesti noin neljätoista ja puoli tuntia.
Monilla tiimeillä omat palvelimet toimivat kyseisenä aamuna moitteettomasti. Heidän käytettävyysvahtinsa loistivat vihreinä samalla kun tunnistautumispalvelu, maksunvälittäjä tai sähköpostipalvelu olivat polvillaan. Useimmat katkokset ovat kuitenkin maltillisempia: sähköpostitoimittajasi viivyttää viestejä neljänkymmenen minuutin ajan, asiakastuki hukkuu kyselyihin saapumattomista salasanan palautuslinkeistä, ja lopulta joku löytää toimittajan tilasivun, jolla on lukenut «Heikentynyt suorituskyky» jo puoli tuntia.
Työskentelen Page Deltasilla, joka tarkkailee julkisia verkkosivuja ja hälyttää, kun niissä tapahtuu sinulle merkityksellisiä muutoksia; huomioi tämä tausta, kun vertaan sitä muihin ratkaisuihin jäljempänä. Tämä artikkeli käy läpi, miten suuntaat valvonnan kriittisten toimittajiesi tilasivuille: minkä URL-osoitteen valitset, miten laadit kohinaa karsivan ohjeistuksen (briefin), minne hälytykset kannattaa ohjata ja missä tämän menetelmän rajat tulevat vastaan.
Miksi oma valvontasi näyttää vihreää
Oma käytettävyysvahtisi kysyy vain, vastaako oma sivustosi pyyntöihin – ja ulkopuolisen toimittajan katkoksen aikana se vastaa useimmiten normaalisti. APM-työkalusi näyttää virhepiikin kyseiseen toimittajaan kohdistuvissa kutsuissa, mutta se ei kykene erottamaan, johtuuko vika omasta koodistasi vai heidän infrastruktuuristaan. Juuri tähän tilasivu vastaa, ja vastaus määrittää seuraavat toimenpiteesi: et peruuta hätäisesti tuntia aiemmin tehtyä julkaisua; kerrot asiakastuelle kyseessä olevan tunnettu ulkoinen häiriö ja harkitset oman tilasivusi päivittämistä.
Miksi et siis tilaisi ilmoituksia suoraan toimittajan sivulta? Sinun kannattaa tehdä niin, jos se riittää tarpeisiisi. Monet tilasivut toimivat Atlassian Statuspage -alustalla ja tarjoavat hälytyksiä sähköpostitse, tekstiviestillä, Slackissa, Teamsissa tai webhookeilla sen mukaan, mitä toimittaja on ottanut käyttöön. Ongelmat alkavat kahdeksannen toimittajan kohdalla: jokainen tilaus on erillinen määritys, joka usein päätyy yhden ainoan henkilön postilaatikkoon, jokainen toimittaja muotoilee viestinsä eri tavalla, eikä rajaaminen vain käyttämiisi komponentteihin ole aina mahdollista. Osa toimittajista ylläpitää jopa omatekoisia sivuja ilman minkäänlaista tilauspainiketta.
Verkkosivujen muutosvahti tarjoaa yhtenäisen toimintamallin jokaiselle toimittajalle: liität tilasivun URL-osoitteen, kuvaat kiinnostuksen kohteesi yhdellä lauseella, ja jokainen hälytys saapuu samaan kanavaan samanmuotoisena.
Mitä sivuja sinun tulisi valvoa?
Valitse sivu, joka näyttää reaaliaikaisen tilanteen juuri nyt, yleensä status.toimittaja.fi. Älä valitse yrityksen pääsivua tai luotettavuutta hehkuttavaa markkinointisivua. Useimmat SaaS-tilasivut noudattavat samaa rakennetta: luettelo komponenteista tilatietoineen, ilmoituspalkki aktiivisista häiriöistä, tulevat huoltoikkunat sekä lyhyt luettelo tuoreista häiriöistä linkkeineen koko arkistoon.
Aloita niistä riippuvuuksista, joiden kaatumisen asiakkaasi huomaisivat välittömästi. Useimmille ohjelmistotiimeille luettelo on lyhyt.
| Riippuvuus | Mitä asiakkaasi huomaavat katkoksen aikana |
|---|---|
| Maksunvälitys | Kassamaksu epäonnistuu tai tilausten uusinnat eivät mene läpi |
| Kirjautuminen ja tunnistautuminen | Kukaan ei pääse kirjautumaan tililleen |
| Sähköposti- ja tekstiviestilähetykset | Salasanan palautukset ja kutsut eivät koskaan saavu |
| Pilvialue, CDN tai DNS | Kaikki muuttuu tuskallisen hitaaksi tai täysin saavuttamattomaksi |
| Tekoälymallien API-rajapinnat | Tekoälyominaisuutesi aikakatkaisevat tai palauttavat virheitä |
Jos voit valvoa vain muutamaa, aloita ylhäältä. Maksu- ja kirjautumisongelmat muuttuvat tukipyynnöiksi minuuteissa, kun taas hidastunut CDN saattaa aluksi näkyä vain järjestelmämetriikoissasi. Ilmaispaketin 10 URL-osoitetta kattavat nämä kaikki viisi riviä ja jättävät vielä tilaa alla esitellyille lisäsivuille.
Kaksi muuta sivutyyppiä on hyödyllistä tietää. Históriasivu (usein /history) on loistava toinen vahti kriittiselle toimittajalle: lyhyt katkos voi alkaa ja tulla ratkaistuksi pääsivun kahden tarkistuksen välissä, mutta se jää listattuna historiaan, jolloin saat siitä tiedon jälkikäteen. Pitkäkestoisen häiriön aikana voit lisätä myös kyseisen häiriön oman tilannesivun väliaikaiseksi vahdiksi seurataksesi jokaista päivitystä. Poista se häiriön päätyttyä, jotta se ei kuluta URL-kiintiötäsi.
Käyttöönotto vaihe vaiheelta
Käyttöönotto vie noin viisi minuuttia ja noudattaa samaa logiikkaa kuin muutoslokien valvontaoppaamme, vain ohjeistus mukautetaan tilanteeseen.
1. Luo tili ja määritä kanava
Rekisteröidy ilmaiseksi, siirry Kanavat-osioon ja lisää paikka, jonne hälytysten tulisi saapua. Suosittelen luomaan erillisen kanavan kuten #vendor-status yleisen #engineering-kanavan sijaan, johon ilmoitukset helposti hukkuvat. Slack, Discord ja Microsoft Teams vaativat saapuvan webhook-osoitteen. Teamsissa napsauta kanavaa hiiren kakkospainikkeella, valitse Liittimet, sitten Saapuva webhook, Määritä ja liitä URL-osoite Page Deltasiin. Sähköpostin osalta vastaanottajan on ensin vahvistettava vahvistusviesti. Napsauta Lähetä testi jokaisessa kanavassa varmistaaksesi perilletulon.
2. Lisää vahti ohjeistuksella
Napsauta Uusi vahti ja liitä tilasivun URL-osoite. Pidä yksi toimittaja vahtia kohden, jotta kukin ohjeistus voi nimetä juuri kyseisen toimittajan komponentit, ja jos eri tiimit seuraavat eri palveluita, liitä kuhunkin vahtiin eri hälytyskanava.
Tilasivut muuttuvat useammin kuin arvaisi, jopa rauhallisena päivänä: käytettävyysprosentit elävät hienoisesti, «viimeksi päivitetty» -aikaleimat siirtyvät eteenpäin, ja tuoreiden häiriöiden luettelo siirtyy päivällä eteenpäin uudella «Ei raportoituja häiriöitä» -rivillä. Suunnitellut huollot ilmoitetaan viikkoja etukäteen. Perinteinen diff-työkalu reagoisi näihin kaikkiin.
Vahdin kuvaus toimii kehotteena, jonka kielimallimme (LLM) lukee arvioidessaan muutoksen merkittävyyttä. Kirjoita se kuin ohjeistaisit kollegaa, joka tarkkailee sivua puolestasi. Sähköpostipalvelulle seuraavanlainen ohjeistus toimii täsmällisesti:
Sähköpostipalvelumme tilasivu. Käytämme ainoastaan komponentteja
Email API ja Webhooks US-alueella.
Hälytä minulle, kun julkaistaan uusi häiriö, joka vaikuttaa näihin komponentteihin
tai kyseiseen alueeseen, kun sen tila tai vakavuus muuttuu tai kun se on ratkaistu.
Hälytä, jos jompikumpi komponenteista siirtyy pois tilasta Operational.
Ohita käytettävyysprosentit, "viimeksi päivitetty" -aikaleimat, päivittäiset
"Ei raportoituja häiriöitä" -rivit sekä muiden alueiden häiriöt.
Mainitse suunniteltu huolto vain, jos se alkaa 48 tunnin sisällä.
Tee yhteenveto vaikuttavasta komponentista, nykytilasta ja viimeisimmästä päivityksestä.Poisrajausrivi tekee suurimman osan työstä. Jos jätät sen pois, vietät ensimmäisen viikkosi vastaanottaen hälytyksiä keskiyöllä häiriötaulukon rullatessa eteenpäin.
Suuren pilvipalvelun kohdalla alueiden ja palveluiden nimet ovat vieläkin olennaisempia. Julkinen pilvipaneeli kattaa satoja palveluita kymmenillä alueilla, ja tavanomaisena viikkona jossain päin maailmaa on lähes aina jokin osa heikentyneessä tilassa. Nimeä nimenomaisesti ne alueet ja palvelut, joilla oma järjestelmäsi toimii, ja pyydä ilmoituksia ainoastaan niistä.
3. Anna ensimmäisen tarkistuksen asettaa vertailupohja
Uusi vahti tekee ensimmäisen tarkistuksensa pian luomisen jälkeen. Tämä tarkistus tallentaa lähtötilanteen, joten et saa turhaa hälytystä ensimmäisellä minuutilla, ellei sivu muutu kahden tarkistuksen välissä. Avaa vahti sen jälkeen ja tarkista kuvakaappaus varmistaaksesi, että se rajautui oikeaan komponenttilistaan.
4. Tarkista heti, kun jokin tuntuu epäilyttävältä
Page Deltasissa et määritä kiinteää tarkistusväliä. Aikataulu on mukautuva: usein muuttuvat sivut tarkistetaan tiheämmin, ja maksulliset tilaukset saavat jonossa etusijan. Koska tilasivu on yleensä hiljainen, virhemäärien noustessa ja toimittajaa epäiltäessä voit napsauttaa Tarkista nyt sen vahdin kohdalta. Sama toiminto on käytettävissä API-rajapinnan kautta, rajattuna yhteen kertaan minuutissa vahtia kohden:
curl -X POST \
-H "Authorization: Bearer $PAGEDELTAS_TOKEN" \
https://api.pagedeltas.com/api/monitors/$MONITOR_ID/check-nowToiminta hälytyksen saapuessa
Kun muutos vastaa ohjeistustasi, saat yhden selkokielisen yhteenvedon sekä kuvakaappaukset tilanteesta ennen ja jälkeen. Jos käytät allekirjoitettua webhookia, viestirunko näyttää tältä (arvot ovat esimerkinomaisia):
{
"event": "change.detected",
"monitor_id": "01HX7Q...",
"monitor_url": "https://status.example-mail.com/",
"monitor_name": "Sähköpostitoimittajan tila",
"change_id": "...",
"detected_at": "2026-10-14T07:21:00Z",
"summary": "Uusi häiriö: viivästyneitä sähköpostilähetyksiä US-alueella. Email API muuttui tilasta Operational tilaan Degraded Performance. Tila: Tutkinnassa.",
"before_screenshot_url": "https://.../before.png",
"after_screenshot_url": "https://.../after.png",
"dashboard_url": "https://app.pagedeltas.com/monitors/..."
}Hälytyksen ensimmäisenä näkevän kannattaa vastata ketjuun kertoen, mitä tämä tarkoittaa omalle palvelullenne. Asiakastuki voi kiinnittää valmiin vastauksen tunnetusta häiriöstä ennen kuin tukipyyntöjä alkaa kasaantua. Päivystävä kehittäjä voi lopettaa syyttömän koodijulkaisun perkaamisen, ja jos katkos näkyy suoraan loppukäyttäjille, päivittäkää oma tilasivunne, jotta asiakkaat kuulevat asiasta ensimmäisenä teiltä.
Jos tiimisi käyttää PagerDutyä tai muuta häiriönhallintajärjestelmää, allekirjoitettu webhook voi välittää tiedot sinne pienen palvelittoman funktion kautta. Koska tietueemme ei ole PagerDutyn natiivimuodossa, muutama koodirivi riittää allekirjoituksen tarkistamiseen ja tapahtuman eteenpäin välittämiseen:
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;
}Laske tiiviste raakaviestistä ennen sen jäsentämistä JSONiksi, muuten allekirjoitus ei täsmää. Kanavadokumentaatiomme esittelee yksityiskohdat. Kukin hälytys lähetetään kerran kanavaa kohden ilman automaattista uudelleenyritystä: korvaamattomille toimittajille kannattaa määrittää toinen, eri tyyppinen kanava (kuten Slack yhdistettynä sähköpostiin) siltä varalta, että Slackissa tai välityspalvelussa on tilapäinen häiriö.
Rajoitukset, jotka on syytä tiedostaa
Tämä ratkaisu välittää sen, mitä toimittaja kertoo julkisesti, ja siihen liittyy muutama olennainen rajoitus, jotka kannattaa ymmärtää.
Toimittajat viivyttelevät usein häiriöistä ilmoittamista. Omat virhekuvaajasi näyttävät toisinaan ongelmat ennen kuin tilasivu myöntää mitään: pidä hälytystä siksi pikemminkin vahvistuksena kuin ihka ensimmäisenä varoituksena. Se ei myöskään korvaa oman API-rajapintasi synteettisiä testejä tai käytettävyysvalvontaa: ne kertovat sinulle, että oma tuotteesi on rikki; tilasivu kertoo miksi.
Tarkistusten välissä muutos havaitaan seuraavalla ajastetulla kierroksella ilman taattua minuuttiaikataulua. Niille yhdelle tai kahdelle toimittajalle, joiden kohdalla jokainen minuutti ratkaisee, pidä voimassa myös toimittajan oma suoratilaus ja käytä Page Deltasia loppuihin. Lisäksi luemme ainoastaan julkisia sivuja: tila, joka näkyy vain kirjautumisen takana hallintapaneelissa, jää toistaiseksi tavoittamattomiin.
Vertaamme sivujen tekstisisältöä. Jos toimittaja esittää tilanteen ainoastaan värillisenä pallurana ilman mitään sanallista muutosta, emme havaitse sitä. Visualping mahdollistaa pikselialueen tarkkailun ja sopii paremmin tuohon yksittäistapaukseen. Lopuksi: jos itse tilasivu kaatuu, tarkistukset epäonnistuvat hälytyksen sijaan, ja 10 peräkkäisen epäonnistumisen jälkeen vahti keskeytyy automaattisesti ja ylläpitäjät saavat ilmoituksen.
Aloita kolmella toimittajalla
Valitse kolme toimittajaa, joiden katkos sattuisi eniten – todennäköisesti maksut, kirjautuminen ja sähköposti. Liitä niiden tilasivujen URL-osoitteet, mukauta yllä oleva ohjeistus omilla komponenteillasi ja alueillasi ja lähetä testihälytys kanavalle #vendor-status. Ilmaisversio kattaa 10 URL-osoitetta tekoälysuodatuksella, kaikki hälytyskanavat ja API-yhteyden ilman luottokorttia. Aloita valvonta ilmaiseksi.
Julien, tuotepäällikkö Page Deltasilla