Kort svar: En statusside er den side, dine kunder tjekker – og din support henviser til – når noget er nede. Dens vigtigste egenskab er, at den ikke bor sammen med sitet: læg den hos en hostet statusside-tjeneste eller på anden infrastruktur, ellers går den ned sammen med det, den skulle fortælle om. Vis få komponenter, ærlig status med tidsstempler, og lov altid næste opdatering („ny status kl. 14:30“). Opdatér statussiden før indbakken: én opdatering dér sparer mange enkeltsvar.
Fagligt gennemgået: 2. oktober 2026
Når sitet er nede, opstår et kommunikationstomrum. Kunderne ved ikke, om I ved det, om der arbejdes på det, eller om de skal finde en anden leverandør.
Statussiden fylder tomrummet – billigt, roligt og professionelt. Her er, hvordan du sætter din egen op, hvad den skal vise, og hvilken rutine der skal ligge bag.
Hvorfor en statusside betaler sig
Regnestykket er enkelt: jo længere ingen ved noget, desto flere henvendelser kommer der. Og hver af dem skal besvares af præcis de mennesker, der burde fejlfinde i stedet.
Statussiden vender strømmen:
- Supporten svarer med ét link i stedet for at skrive det samme svar igen og igen.
- Kunderne kan selv følge med – og abonnere på opdateringer, hvis løsningen understøtter det.
- Telefonen bliver stille nok til, at der kan arbejdes på selve fejlen.
Den bygger også noget mindre målbart: tillid. En virksomhed, der selv fortæller om sine nedbrud med tidsstempler og ærlige forklaringer, virker mere professionel end en, hvor alt „altid virker“ – lige indtil det ikke gør, og ingen siger noget.
Internt giver den ro. Når ledelsen kan følge med på statussiden, ringer den ikke til den, der fejlfinder. Det er pointen fra nedbrudsplanen om at skille kommunikation fra fejlfinding.
Kravet: uafhængig af sitet
Reglen over alle andre: statussiden må ikke dele skæbne med det, den fortæller om. Bor den på samme WordPress, samme server eller bag samme proxy-opsætning som hovedsitet, viser den ingenting – præcis når den skulle arbejde.
I praksis betyder det:
- Anden infrastruktur: en hostet statusside-tjeneste, en statisk side hos en anden udbyder eller i det mindste en anden server end produktionen.
- Et let genkendeligt navn: typisk et subdomæne som status.ditdomæne.dk, peget direkte mod statussidens udbyder – se guiden om subdomæner.
- Ingen afhængighed af hovedsitets proxy eller cache: statussidens DNS-record skal ikke gå gennem den samme CDN- eller firewallopsætning, som kan være en del af problemet.
Vær opmærksom på én grænse: et subdomæne deler domænets DNS. Er selve domænets DNS eller registrering problemet, er status.ditdomæne.dk også væk. Mange tjenester giver derfor også en adresse på deres eget domæne, som kan bruges som reserve – skriv den ned i nødkontaktlisten, så supporten kender den.
Test uafhængigheden én gang: bloker eller sluk hovedsitet i et planlagt vedligeholdelsesvindue (eller simulér det, fx ved at pege et testdomæne forkert), og se, at statussiden stadig svarer. Det kvarter er hele forskellen på en statusside og en pyntegenstand.
Hvad statussiden skal vise
Få komponenter, klart sprog. List de tre til fem dele, kunderne faktisk mærker – fx hjemmeside, webshop eller booking, mail og eventuelt en kundeportal eller et API – med en simpel status pr. del.
| Status | Hvad den betyder for kunden |
|---|---|
| Kører | Alt virker som normalt. |
| Forstyrret | Funktionen virker, men langsomt eller med enkelte fejl. |
| Delvist nede | En del af funktionen virker ikke, fx betaling med én korttype. |
| Nede | Funktionen kan ikke bruges lige nu. |
| Planlagt vedligehold | Kendt, annonceret pause med start- og sluttidspunkt. |
Hver hændelse får en lille log med tidsstempler, skrevet til mennesker:
- 13:42 – Vi undersøger fejl på betalinger i webshoppen.
- 14:10 – Årsagen er fundet. Vi udruller en rettelse.
- 14:35 – Betalinger virker igen. Vi holder øje de næste timer.
Hver opdatering svarer på fire ting: hvad virker ikke, hvad betyder det for dig, hvad gør vi, og hvornår kommer næste status. Aldrig serverjargon.
To detaljer løfter siden fra fin til professionel:
- Løftet om næste opdatering: „ny status senest 14:30“ – og hold det, også når nyheden blot er „vi arbejder stadig på det“.
- Historikken: afsluttede hændelser med varighed og kort forklaring, så nye kunder kan se, at nedbrud håndteres åbent.
Planlagt vedligehold annonceres samme sted. Så er kanalen kendt, før den bliver nødvendig.
Løsninger: hostet, indbygget eller egen
Der er tre veje, og de passer til forskellige behov:
| Løsning | Fordele | Ulemper |
|---|---|---|
| Hostet statusside-tjeneste | Bygget til formålet: komponenter, hændelseslog, abonnement på opdateringer. Uafhængighed er selve produktet. | Endnu en tjeneste og konto at holde styr på. Funktioner og priser varierer. |
| Overvågningens indbyggede statusside | Mange uptime-tjenester kan publicere en offentlig side direkte fra målingerne. Næsten intet ekstra vedligehold. | Mindre kontrol over teksten. Viser oppetid, men forklarer ikke altid, hvad det betyder for kunden. |
| Egen simpel side | En statisk side på separat infrastruktur. Fuld frihed over indhold og design. | Mest arbejde. Skal opdateres manuelt under pres og have sin egen adgang. |
Vælg efter ét kriterium: den løsning, I faktisk får opdateret under pres. En flot statusside, som ingen tør eller kan røre kl. 23, er ingen statusside.
Skabelontekster skrevet i fredstid
Det sværeste under et nedbrud er ofte at formulere sig. Skriv derfor tre skabeloner på forhånd, og læg dem i driftsdokumentationen:
- Vi undersøger: „Vi oplever i øjeblikket problemer med [komponent]. Vi undersøger årsagen. Næste opdatering senest kl. [tid].“
- Årsag fundet: „Vi har fundet årsagen til problemerne med [komponent] og arbejder på en løsning. [Hvad kunden kan gøre imens]. Næste opdatering senest kl. [tid].“
- Løst: „[Komponent] virker igen fra kl. [tid]. Problemet skyldtes [kort, forståelig forklaring]. Vi beklager ulejligheden.“
Skabelonerne fjerner skriveblokaden midt i stressen – og sikrer, at tonen er rolig og ensartet, uanset hvem der opdaterer.
Gør statussiden let at finde
En statusside, ingen kender, hjælper ikke. Sørg for, at den kan findes de steder, kunderne kigger, når noget ikke virker:
- Et link i footeren på hovedsitet og på kontaktsiden.
- En linje i supportens autosvar under hændelser: „Se aktuel status på status.ditdomæne.dk“.
- En henvisning i telefonsvareren eller kø-beskeden, hvis I har telefonsupport.
- Et opslag på de sociale kanaler, I i forvejen bruger, med link til statussiden i stedet for lange forklaringer.
Tilbyder løsningen abonnement på mail eller RSS, så nævn det. Kunder, der selv får besked, skriver ikke for at spørge.
Kommunikationsrutinen
Statussiden er kun så god som rutinen bag den. Skriv rutinen ind i nedbrudsplanen:
- Hvem opdaterer: kommunikationsrollen – ikke den, der fejlfinder.
- Hvornår: første besked inden for cirka 15 minutter efter bekræftet nedbrud. Hellere „vi undersøger“ tidligt end en perfekt besked sent.
- Med hvad: de tre skabelontekster ovenfor.
- Hvor ofte: mindst lige så ofte, som I har lovet – og altid med næste tidspunkt.
Efter hændelsen føres varighed og årsag både til statussidens historik og til ændringsloggen. Læringen samles op i post mortem-rutinen, så samme fejl ikke gentager sig.
Husk også fundamentet. En statusside fungerer bedst, når den mest viser „alt kører“: stabil hosting, overvågning, der opdager fejl hurtigt, og en testet backup gør nedbrud kortere og sjældnere.
Tjekliste til statussiden
- Statussiden ligger på anden infrastruktur end hovedsitet.
- Uafhængigheden er testet mindst én gang.
- Der er en reserveadresse, hvis domænets DNS er problemet.
- Tre til fem komponenter med klare statusniveauer.
- Tre skabelontekster ligger klar i driftsdokumentationen.
- Det er aftalt, hvem der opdaterer, og hvor hurtigt.
- Statussiden er linket fra footer, kontaktside og autosvar.
Læs også
- Hub: Driftshåndbogen
- Uptime-overvågning: værktøjer, intervaller og alarmer, der ikke larmer
- Nedbrudsplanen: hvem gør hvad, når sitet er nede kl. 23?
- Efter nedbruddet: post mortem, der forhindrer gentagelsen
- Nødkontakter og eskalation: hosting, bureau og betalingsudbyder
- WordPress hosting hos Hostious – daglig backup med selvbetjent gendannelse og dansk support døgnet rundt
Ofte stillede spørgsmål om statussider
Kan statussiden ligge på vores eget WordPress?
Nej. Så er den nede sammen med sitet, når den skal bruges. Læg den på separat infrastruktur, fx hos en hostet statusside-tjeneste eller som en statisk side hos en anden udbyder.
Hvor hurtigt skal første opdatering ud?
Inden for cirka 15 minutter efter bekræftet nedbrud – også selv om beskeden kun er „vi undersøger“. Lov næste opdatering med klokkeslæt, og hold løftet.
Hvad skal der stå under et nedbrud?
Hvad der ikke virker, hvad det betyder for kunden, hvad I gør, og hvornår næste status kommer. Brug tidsstempler og klart sprog uden teknisk jargon.
Er et subdomæne nok til at gøre statussiden uafhængig?
Det er et godt udgangspunkt, hvis subdomænet peger på anden infrastruktur. Men et subdomæne deler domænets DNS, så hav også en reserveadresse på udbyderens eget domæne til de sjældne tilfælde, hvor selve domænet er problemet.
Skal planlagt vedligehold også på statussiden?
Ja. Annoncér tidspunkt, varighed og hvad der berøres i god tid. Så lærer kunderne kanalen at kende, før der opstår et uplanlagt nedbrud.
Udgivet 2. september 2026Opdateret 3. oktober 2026Fagligt gennemgået 2. oktober 2026