Status Page bedste praksis: Hvad du skal inkludere når dit site går ned

En Status Page er det første sted, brugere tjekker når noget går i stykker. Hvis den er forvirrende, forældet eller mangler information, har du spildt din eneste chance for at kommunikere tydeligt i et stressende øjeblik.

Her er hvordan du bygger en Status Page, der faktisk hjælper.

Anatomien af en god Status Page

1. Overordnet statusindikator

Det første en besøgende bør se er et klart, umiddelbart svar på spørgsmålet: "Er alt OK?"

Vis én af tre tilstande øverst på siden:

• All Systems Operational — Grøn. Alt kører normalt.
• Partial Outage — Gul. Nogle services er påvirket.
• Major Outage — Rød. En kernetjeneste er nede.

Tving ikke brugere til at scanne gennem component-lister for at finde ud af om der er et problem. Status bør være tydelig ved første øjekast.

2. Component-liste

Under den globale status skal du liste hver tjeneste du overvåger med dens individuelle status:

• ✅ Operational
• ⚠️ Degraded Performance
• ❌ Down
• 🔧 Maintenance

Navngiv components i klart sprog, der matcher hvad brugerne kender: "App" ikke "web-frontend-prod-v2," "API" ikke "gateway.core.services.rest."

Gruppér relaterede components. Hvis du har en mikroservices-arkitektur, så list services under deres produktområder i stedet for at smide alle 30 components i én liste.

3. Aktive Incidents

Når noget er galt, er sektionen for aktive incidents den vigtigste del af siden. Inkludér:

• Titel — "Degraded API Response Times" eller "Major Outage — Checkout Unavailable"
• Beskrivelse — Hvad sker der, hvad er påvirket, og hvad gør du
• Tidslinje — Opdateringer med tidsstempler mens Incident'en skrider frem
• Påvirkede components — Markér de services, der er ramt

Opdatér tidslinjen hyppigt. En Status Page der ikke er blevet opdateret på 3 timer er værre end slet ingen Status Page — det signalerer, at ingen holder øje.

4. Incident-historik

Når en Incident er løst, flytter den til historikloggen. Det tjener flere formål:

• Viser at du er gennemsigtig om tidligere problemer
• Hjælper kunder med at forstå din pålidelighedshistorik
• Giver data til dine egne post-mortem-analyser
• Understøtter SLA-rapportering

Gem mindst 90 dages incident-historik synligt. Nogle tjenester beholder alt på ubestemt tid.

5. Abonnentnotifikationer

Lad brugere abonnere på statusændringer, så de ikke behøver at genopfriske siden. Understøt som minimum:

• E-mail-notifikationer — Når en Incident oprettes, opdateres eller løses
• Valgfrit SMS- eller webhook-integrationer

Send notifikationer ved nøgleøjeblikke:

• Incident oprettet
• Incident opdateret med ny information
• Vedligeholdelse planlagt
• Vedligeholdelse afsluttet
• Incident løst

Design bedste praksis

Brug dit brand

Din Status Page skal ligne den tilhører din virksomhed. Match:

• Logo og typografi
• Brandfarver til det overordnede tema
• Dit domæne (status.dinvirksomhed.dk)

En Status Page der ser generisk ud eller bruger standard-branding skaber mistillid. Hvis den ikke ser officiel ud, vil brugere ikke tro på opdateringerne.

Hold det enkelt

En Status Page er ikke et marketingsite. Inkludér ikke:

• Hero-animationer
• Pop-ups eller modaler
• Flere calls to action
• Tung JavaScript der gør siden langsom

Din Status Page bør indlæses hurtigt selv på langsomme forbindelser. Hold dig til statisk HTML og CSS hvor muligt.

Mobile First

De fleste brugere der tjekker en Status Page gør det på deres telefon — især under et udfald. Sørg for:

• Tekst er læsbar uden at zoome
• Tabeller og component-lister brydes korrekt
• Abonnementsformularen er nem at udfylde på mobil

Kommunikation bedste praksis

Skriv til læseren

Incident-opdateringer bør besvare tre spørgsmål:

1. Hvad skete der? — "Vi oplevede et problem med databaseforbindelsen."
2. Hvad gør vi? — "Vi har skiftet til replikaen og undersøger grundårsagen."
3. Hvornår er det løst? — "Vi forventer løsning inden for 30 minutter."

Undgå ingeniør-jargon. "Memory pressure on the primary replica" betyder intet for brugere. "Databasen kører langsomt" gør.

Opdatér hyppigt

Under en aktiv Incident bør du opdatere Status Page hvert 30. minut, selv hvis der ikke er nyt at rapportere. "Undersøger stadig" er bedre end radiotavshed.

Eksempel på god opdateringsplan:

• T+0: Incident oprettet — "Vi undersøger rapporter om..."
• T+15: "Vi har identificeret problemet som..."
• T+30: "Vi implementerer en rettelse..."
• T+45: "Rettelsen rulles ud..."
• T+60: "Tjenesten er genoprettet. Vi overvåger..."

Planlæg vedligeholdelse proaktivt

Vent ikke til et planlagt vedligeholdelsesvindue starter med at opdatere din Status Page. Opret vedligeholdelsesposten 24–48 timer i forvejen, så abonnenter bliver notificeret og brugere ved hvad de kan forvente.

Almindelige fejl

Slet ikke at have en Status Page. Enhver virksomhed med en onlinetjeneste har brug for én. Opsæt den før du får brug for den.

At oprette en Status Page men ikke opdatere den under udfald. En forældet Status Page er værre end ingen — den viser at du ikke bekymrer dig nok til at kommunikere.

At bruge alt for teknisk sprog. Dit publikum inkluderer ikke-tekniske interessenter, kunder og ledelse. Skriv til den almindelige læser.

At gøre siden langsom eller svær at navigere. En Status Page bør indlæses øjeblikkeligt og være læsbar ved første øjekast.

Ikke at tillade abonnementer. Hvis brugere manuelt skal genopfriske for at få opdateringer, bliver de frustrerede, og dit support-team vil høre om det.

Den gyldne regel

En god Status Page reducerer supportbilletter. En dårlig Status Page øger dem. Hver design- og indholdsbeslutning bør måles op mod den målestok.

Opsæt en professionel Status Page i dag. Start gratis hos isthisthing.online — monitors, Status Page og abonnentnotifikationer inkluderet.