Nedbrudsplanen: hvem gør hvad, når sitet er nede kl. 23?

Kort svar: Når sitet er nede kl. 23, er improvisation den dårligste plan. En nedbrudsplan på én side løser det med tre roller (fejlfinder, kommunikatør og beslutter – gerne samme person, der tager rollerne i den rækkefølge), et fast første kvarter (bekræft nedbruddet udefra, tjek hostingens driftsstatus, slå op i ændringsloggen og rul den seneste ændring tilbage) og et beslutningstræ: egen ændring giver rollback, en hostinghændelse giver supportsag og statusside, og er årsagen uklar, eskalerer du efter nødkontaktlisten. Skriv planen i fredstid, print den, og øv den én gang om året.

Fagligt gennemgået: 2. oktober 2026

Nedbrud er ikke et spørgsmål om hvis, men om hvornår – og om der så findes en plan eller kun adrenalin. Uden plan går den første tid ofte med at lede efter adgangskoder og diskutere, hvem der ringer til hvem. Med plan går den med at finde årsagen.

Her er planen klar til at skrive af: rollerne, det første kvarter, beslutningstræet, kommunikationen og opfølgningen – plus en skabelon, du kan printe.

De tre roller

Arbejdet under et nedbrud består af tre opgaver, der forstyrrer hinanden, når de blandes:

• Fejlfinderen undersøger og retter – og skal have ro. Hver „er der nyt?“-afbrydelse koster koncentration.
• Kommunikatøren opdaterer statussiden, svarer support og holder ledelsen orienteret, så fejlfinderen slipper.
• Beslutteren træffer de få valg, teknik ikke kan træffe: „Ringer vi bureauet ind nu?“ eller „Lukker vi for betalinger, til det er løst?“

I en lille virksomhed er alle tre ofte samme person – og netop derfor skal rollerne stå på skrift. Så ved du, at første opgave er fejlfinding, at statussiden opdateres på faste tidspunkter i stedet for konstant, og at eskalering er en beslutning efter planen – ikke et nederlag.

Er I flere, fordeles rollerne i det første opkald, før nogen åbner en terminal.

1. Bekræft og afgræns (de første 5 minutter)

Det første kvarter er en tjekliste, ikke en undersøgelse. Start med at bekræfte, at nedbruddet er reelt:

• Bekræft udefra: er sitet nede for alle eller kun for dig? Prøv over mobilnet i stedet for wifi, brug et eksternt tjekværktøj, og se om uptime-overvågningen har slået alarm. En del formodede nedbrud skyldes lokal DNS, cache eller netværk.
• Afgræns: er alt nede eller kun én funktion – checkout, mail eller login? Det afgør både hastværket og hvilket spor, du skal følge.
• Notér tidspunktet og de første observationer, fx fejlkode og fejltekst. De bliver guld for support og for den senere opfølgning.

2. Tjek driftsstatus og ændringsloggen (minut 5–10)

Tjek derefter, om problemet ligger hos udbyderen. Er der en kendt hændelse hos hostingen, er dit job primært at kommunikere og følge med – ikke at „rette“ i noget, der ikke er din fejl.

Slå så op i ændringsloggen. Mange selvforskyldte nedbrud kommer kort efter en ændring: en opdatering, et nyt plugin eller en DNS-rettelse. Finder du en sandsynlig synder, så rul tilbage først og analysér bagefter.

3. Første status ud (senest efter 15 minutter)

Send den første status til kunderne, også selvom du endnu ikke kender årsagen: „Vi undersøger et problem med X. Næste opdatering kl. Y.“ Først derefter begynder den egentlige fejlfinding – med logs og systematik frem for tilfældige genstarter.

Beslutningstræet

Efter kvarteret står du typisk i én af fire situationer, og planen anviser vejen i hver:

Situation	Hvad du gør	Hvad du undlader
Egen ændring	Rul tilbage, bekræft at sitet virker, dokumentér	At genindføre ændringen samme aften – gør det i dagtimerne med test
Hostinghændelse	Opret sag eller følg driftsstatus, opdatér statussiden med udbyderens oplysninger	At fejlrette i noget, der ikke er din fejl
Kendt fejltype	Følg opskriften i driftsdokumentationen, fx fuld disk, databasefejl eller udløbet certifikat	At springe logs over og gætte
Uklar årsag	Eskalér efter 30–45 minutter med konkrete observationer	„Jeg prøver lige lidt endnu“

Til kendte fejltyper hjælper guiden til loglæsning med diagnosen. Ved uklar årsag går du til nødkontaktlisten: først hostingsupport med konkrete observationer, derefter bureau eller udvikler.

Skriv de fire scenarier ind i jeres beredskabsaftaler, så tærsklerne er aftalt, før de skal bruges.

Kommunikationen undervejs

Kunder tilgiver ofte et nedbrud. Tavshed er sværere at tilgive. Rutinen er derfor fast:

1. Statussiden opdateres først – inden for 15 minutter og med løfte om næste opdatering.
2. Support svarer med et link til statussiden i stedet for individuelle forklaringer.
3. Direkte besked på mail eller sms sendes kun, når kunden skal gøre noget, eller når nedbruddet rammer aftaler som ordrer, bookinger eller frister.

Hav skabeloner klar i planen – „vi undersøger“, „årsag fundet“ og „løst“ – så ingen skal formulere sig under pres. Tonen er ærlig og konkret, uden dramatik og uden tekniske undskyldninger. „Betalinger fejlede mellem 22.41 og 23.37; ingen gennemførte ordrer er gået tabt“ er ofte alt, kunden har brug for – forudsat at det er tjekket.

Internt gælder samme disciplin: ledelsen følger statussiden, ikke fejlfinderens telefon.

Nedbrudsplanen på én side

Planen skal kunne læses af en træt person kl. 23 – også uden adgang til sitet. Print den, og gem en kopi uden for det system, der kan gå ned, fx i en delt mappe og som papir. Den bør indeholde:

• Rollerne og hvem der normalt har dem – med stedfortræder.
• Tjeklisten for det første kvarter.
• Links til overvågning, hostingens driftsstatus, ændringsloggen og statussiden.
• Nødkontakter med telefonnumre, kundenumre og aftalte svartider.
• Hvor adgangene ligger, fx i en fælles adgangskodemanager – aldrig selve koderne på papiret.
• De tre kommunikationsskabeloner.
• Beslutningstræet med tærsklen for eskalering.

Tip: Skriv datoen for seneste gennemgang øverst på planen. En plan med forældede numre er næsten værre end ingen plan, fordi den giver falsk tryghed.

Bagefter: luk læringen ind

Når pulsen er nede, samles trådene inden for en uge: tidslinje og årsag i to afsnit, én forebyggende ændring og én procesforbedring. Formatet står i guiden til post mortem. Hændelsen føres også i ændringsloggen og i statussidens historik.

Test derefter planen. En årlig skrivebordsøvelse – „sitet er nede nu, hvad gør vi?“ gennemspillet på 20 minutter – afslører forældede numre og manglende adgange, længe før virkeligheden gør.

Vælg også et fundament, hvor planen sjældent skal i brug. På WordPress hosting hos Hostious får du daglig og manuel backup med selvbetjent gendannelse, servere i Europa og dansk support døgnet rundt, der kan kontaktes også kl. 23. Så bliver nedbruddet det, det bør være: en procedure, ikke en krise.

Læs også

• Hub: Driftshåndbogen
• Din egen statusside: informér kunder ved nedbrud
• Nødkontakter og eskalation
• Efter nedbruddet: post mortem
• Gendan fra backup uden at miste nye ordrer
• WordPress serviceaftale – den løbende drift håndteret for dig; inkluderet i WordPress hosting fra WP StartUp

Ofte stillede spørgsmål om nedbrudsplaner

Hvad er det første, jeg skal gøre, når sitet er nede?

Bekræft det udefra (er det nede for alle?), tjek hostingens driftsstatus, og slå op i ændringsloggen. Den seneste ændring er ofte den mest sandsynlige årsag – rul den tilbage først.

Hvornår skal jeg eskalere til support eller bureau?

Når der ikke er nogen sandsynlig årsag efter 30–45 minutter – med konkrete observationer i hånden. „Jeg prøver lige lidt endnu“ er nedbruddets dyreste sætning.

Behøver en lille virksomhed roller, når vi kun er én?

Ja – som rækkefølge: fejlfind først, kommunikér på faste tidspunkter, og beslut eskalering efter planen. Rollerne på skrift forhindrer, at alt sker på én gang, og intet bliver gjort ordentligt.

Hvor skal nedbrudsplanen ligge?

Et sted, der virker, selvom sitet og mailen er nede: som print og i en delt mappe uden for hostingen. Adgangskoder hører ikke til i planen – den skal kun pege på, hvor de ligger.