Sådan bygger du en statusside: komponenter, hændelser og oppetidstjek

En statusside fortæller dine brugere, samlet ét sted, om din service virker. For at bygge en har du brug for en liste over komponenter (hjemmeside, API, betalinger, e-mail), en aktuel status for hver, hændelser med tidsstemplede opdateringer, en historik over tidligere hændelser og eventuelt abonnementer, så folk hører om problemer uden selv at tjekke. Selve siden er enkel. Den vigtige beslutning er, hvor den kører: en statusside skal være oppe, når din app er nede, så den bør ikke dele hosting, database eller deploy-pipeline med det, den rapporterer om.

Hvad en statusside er til

Når noget går i stykker, vil brugerne vide tre ting: er det kun mig, er I klar over det, og hvornår bliver det rettet. En statusside besvarer alle tre uden en flod af supportsager. Den opbygger også tillid over tid, for en synlig hændelseshistorik med ærlige beskrivelser viser, hvordan du håndterer problemer.

Den er ikke et changelog. Nye funktioner hører hjemme på en changelog-side; nedbrud og vedligeholdelse hører hjemme her.

Hvad siden har brug for

Data

Komponentstatusser er som regel en kort, fast liste: Operationel, Nedsat ydelse, Delvist nedbrud, Større nedbrud, Under vedligeholdelse.

Sider

• Offentlig statusside: et samlet banner („Alle systemer er operationelle“ eller den værste aktuelle status), hver komponent med sin status, eventuelle aktive hændelser med deres opdateringer, kommende vedligeholdelse og en 90-dages historikstrimmel, hvis du har tjekdata.
• Hændelsesside: den fulde tidslinje af opdateringer for én hændelse, med egen URL, så supporten kan linke til den.
• Historik: tidligere hændelser pr. måned.
• Abonner: tilmelding via e-mail med bekræftelse og præferencer pr. komponent.
• Admin: opret en hændelse, post opdateringer, skift komponentstatusser, planlæg vedligeholdelse.

Rettigheder

Offentligheden ser alt, der er udgivet. Kun dit team kan poste. Hold admin-login adskilt fra din apps login-system, hvis du kan, så et nedbrud hos din login-udbyder ikke låser dig ude af din egen statusside.

Den vigtigste beslutning: hold den uafhængig

Det er her, de fleste hjemmelavede statussider fejler. Hvis din statusside:

• kører på samme server eller hostingkonto som din app,
• læser fra den samme database,
• sidder bag den samme domeneopsætning eller CDN-konfiguration,
• eller bliver deployet af den samme pipeline,

så vil mange nedbrud tage den med sig, netop når folk har mest brug for den. Praktiske skridt:

• Separat hosting. Et andet projekt eller en anden udbyder end hovedappen.
• Eget subdomæne, fx status.example.com, peget separat i DNS. Se hvordan domæner og DNS virker.
• Egne data. Hændelser ligger i statussidens egen lagring, ikke i din apps database.
• En statisk reserve. Nogle teams gør den offentlige side statisk og genbygger den ved hver opdatering, så der næsten intet er, der kan gå i stykker.

Manuelle opdateringer eller automatiske tjek

Manuelt (start her)

Dit team opretter hændelser og ændrer komponentstatusser i hånden fra admin-siden. Sådan fungerer mange statussider i praksis, for en menneskelig vurdering („betalinger er langsomme for visse kortyper“) er mere nyttig end en automatisk rød prik.

For hurtigt at få besked om problemer, brug en ekstern oppetidsmonitor, der tjekker din app cirka hvert minut og advarer dig via e-mail, sms eller chat. Mange overvågningstjenester har gratis niveauer.

Automatisk

Automatik betyder, at noget regelmæssigt tjekker hver komponent og opdaterer dens status. Det kræver kode, der kører efter en plan, uden for din apps hovedinfrastruktur. To almindelige mønstre:

• En ekstern monitor kalder din statusside via en webhook, når et tjek fejler eller genopretter, og statussiden opdaterer komponenten.
• Et planlagt job i statussidens egen hosting pinger hver komponent og gemmer resultatet. Tjek, hvordan din hosting håndterer planlagte opgaver, før du stoler på det; vores guide om kørsel af baggrundsjob forklarer mulighederne.

Automatiske ændringer kan flakke (oppe, nede, oppe) på et langsomt netværk. Kræv to eller tre fejlede tjek, før en status ændres, og lad et menneske bekræfte, før et større nedbrud bliver annonceret.

Sådan skriver du hændelsesopdateringer

• Post tidligt. „Vi undersøger rapporter om fejlede logins“ inden for få minutter slår en perfekt besked en time senere.
• Skriv, hvad brugerne mærker, ikke hvad der gik i stykker internt.
• Lov tidspunktet for næste opdatering, og hold det.
• Afslut med et kort resumé, når den er løst: hvad der skete, hvor længe, og hvad du ændrer.

En første prompt, der virker

Byg en selvstændig statusside til vores app Parcelio, som hostes separat på status.parcelio.com. Komponenter: Hjemmeside, Tracking-API, Notifikationer, Betalinger, hver med status Operationel, Nedsat ydelse, Delvist nedbrud, Større nedbrud eller Under vedligeholdelse. Den offentlige side viser et samlet banner med den værste aktuelle status, hver komponent med sin status, aktive hændelser med tidsstemplede opdateringer, nyeste først, kommende vedligeholdelse og en liste over tidligere hændelser pr. måned. Hver hændelse har sin egen side. Tilføj en adgangskodebeskyttet adminside til at oprette hændelser (titel, påvirkning, berørte komponenter), poste opdateringer (besked og status: Undersøges, Identificeret, Overvåges, Løst), ændre komponentstatusser og planlægge vedligeholdelse. Tilføj et endpoint POST /api/check-result, som accepterer et komponentnavn og oppe/nede fra en ekstern monitor, beskyttet af et hemmeligt token, og kun markerer en komponent som Nedsat ydelse efter tre fejl i træk. Gem alt i denne apps egen database. Enkelt, roligt design, der indlæses hurtigt på telefoner.

Byggetrin

1. Offentlig side og admin med manuelle hændelser. Det alene er en fungerende statusside.
2. Host den separat og peg et subdomæne på den.
3. Hændelsessider og historik.
4. Vedligeholdelsesvinduer.
5. Abonnementer. Tilmelding via e-mail med dobbelt bekræftelse og notifikationer ved nye hændelser og opdateringer. E-mail kræver en udbyder; se sådan sender du e-mails fra din app.
6. Monitor-webhook, hvis du vil have automatiske statusskift.
7. Kør en øvelse. Opret en falsk hændelse, post opdateringer, luk den, tjek e-mails, og slet den derefter.

Almindelige fejl

• At hoste den sammen med appen. Den hyppigste og alvorligste fejl.
• En side, der altid siger „Alle systemer er operationelle“. Hvis den aldrig viser problemer, holder brugerne op med at stole på den.
• Ingen tidsstempler eller tidszone. Vis altid tider med zonen.
• At stole på din apps login til admin-siden.
• Stilhed mellem opdateringer. „Ingen ændring, vi arbejder stadig på det“ er en gyldig opdatering.
• Flakkende automatiske statusser. Kræv gentagne fejl, før en ændring sker.

Hvornår en hostet statusside-tjeneste er det bedre valg

Hostede statussidetjenester er bygget omkring uafhængighedsproblemet: de kører på separat infrastruktur, håndterer abonnentnotifikationer via e-mail og sms og inkluderer ofte overvågning og integrationer med hændelsesværktøjer. Hvis oppetid er en del af det, dine kunder betaler for, eller du har kontraktlige forpligtelser til at rapportere hændelser, er en dedikeret tjeneste som regel umagen værd. Mange har gratis eller billige niveauer til små teams, så tjek det, før du bygger selv.

Byg selv, når du vil have fuld kontrol over design og formuleringer, når dine behov er enkle (et håndfuld komponenter, manuelle opdateringer), eller når en statusside er en del af et produkt, du bygger til andre.

Bygget med Mythex

På Mythex kan du bygge statussiden som sit eget projekt, adskilt fra din hovedapp, hvilket giver separat hosting og egen database. Beskriv den i chatten, tjek den i live-forhåndsvisningen, publicér den og forbind et subdomæne som status.yourdomain.com (egne domæner er på Pro). Husk, at publicerede Mythex-apps og deres databaser sover, når de er inaktive, og vågner ved næste besøg, så den første indlæsning efter en stille periode kan være langsommere; en enkel, let side hjælper.

Mythex dokumenterer ikke planlagte job, så til automatiske tjek brug en ekstern oppetidsmonitor, der kalder et webhook-endpoint i din statusside (se webhook-opskriften). E-mailvarsler til abonnenter går gennem din egen udbyder, med nøglen gemt som projekthemmelighed (send e-mail-opskriften).

Spørgsmål