Overvåg mere end oppetid: formularer, checkout og søgning

Kort svar: De dyreste fejl er de stille: sitet svarer fint, men formularen sender ikke, checkout afviser kort, eller søgningen finder nul varer – og oppetidsovervågningen ser intet. Overvåg derfor funktionerne: en månedlig testindsendelse og et testkøb, indsendelser gemt i databasen som sikkerhedsnet, et øje på betalingsfejl-raten i gatewayens dashboard – og vigtigst: tørke-alarmer mod din egen baseline. Nul henvendelser i flere dage eller nul ordrer en normal hverdag er en alarm, længe før nogen klager.

Fagligt gennemgået: 2. oktober 2026

Alle kender historien: „Vi undrede os over, at det var så stille – det viste sig, at formularen havde været død i tre uger.“ Fejlen kostede ikke nedetid, men den kostede tre ugers kunder.

Denne guide bygger overvågningslaget oven på oppetid: det, der holder øje med, at forretningen virker – ikke kun at serveren svarer.

De stille fejl

Stille fejl har tre fællestræk:

• Siden svarer. Derfor udløser oppetidsovervågningen ingen alarm.
• Fejlen rammer kun én funktion eller én kundegruppe. Derfor opdages den sent.
• Årsagen er næsten altid en ændring et andet sted: en opdatering ændrede mailafsendelsen, et nyt plugin kolliderede med betalingsmodulet, eller en streng firewall- eller botblokering ramte også rigtige kunder og betalings-callbacks.

Klassikerne er:

• Formularen viser „Tak for din besked“, men mailen sendes aldrig.
• Checkout accepterer danske kort, men afviser udenlandske.
• Søgningen indekserer ikke nye varer.
• Ordrebekræftelser lander i spam.
• Planlagte opgaver som nyhedsbreve, synkroniseringer og abonnementstræk kører ikke.

Hvis ingen overvåger dem, opdages de i regnskabet. Men de er nemme at fange med få faste rutiner, fordi testen bare er at gøre det, kunderne gør.

Overvåg formularerne

Formularer overvåges i tre lag, i stigende ambition.

Testen

Send en rigtig indsendelse gennem hver vigtig formular hver måned – som et fast punkt i månedsrutinen – og bekræft, at den ankommer både i indbakken og i systemet.

Test fra en privat mailadresse og ikke kun fra firmaets egen. Så bliver spamfiltre og afsenderopsætning også prøvet.

Sikkerhedsnettet

Sæt formularpluginet til at gemme indsendelser i databasen og ikke kun sende dem som mail. Så er en fejlende mailafsendelse et irritationsmoment i stedet for tabte kunder – og du kan se i listen, om der faktisk kommer indsendelser ind.

Husk at sætte en slettefrist på de gemte indsendelser, så I ikke opbevarer persondata længere end nødvendigt. Guiden om GDPR i formularer gennemgår det.

Baselinen

Kender du din normal – fx „5–15 henvendelser om ugen“ – er nul i fire-fem dage et signal og ikke bare en stille uge. Sæt en påmindelse eller en automatisering, der reagerer på tørken.

Mange stille formularfejl bunder i mailopsætningen: SPF, DKIM og afsenderdomæne. Kommer der mistænkeligt få mails igennem, så se guiden om mails fra WordPress i spam eller mail-fejlfindingshubben.

Overvåg checkout

Checkout er sitets dyreste funktion og fortjener tre vaner.

Testkøbet

Gennemfør et rigtigt køb hver måned med et rigtigt betalingskort – fx på en billig testvare, der refunderes bagefter. Gå hele vejen gennem kortindtastning, 3D Secure, bekræftelsesside og ordremail. Det tester samtidig kvitteringsflow, lagertræk og eventuelle integrationer til lager eller bogføring.

Et køb i gatewayens testtilstand er nyttigt efter ændringer, men det erstatter ikke det rigtige køb: testtilstanden prøver ikke den live-forbindelse, kunderne bruger. Guiden Testkøb før go-live har den fulde tjekliste.

Fejlraten

Betalingsgatewayens dashboard viser afviste og fejlede betalinger. Kig på raten hver måned. Et hop i afvisninger – især på én korttype, én betalingsmetode eller udenlandske kort – er en stille fejl med en præcis adresse. Se også WooCommerce betaling fejler.

I WooCommerce er det også værd at holde øje med ordrer, der bliver stående som „Afventer betaling“. En stigning kan betyde, at gatewayens callback ikke når frem til sitet – fx fordi en firewall blokerer den.

Tørke-alarmen

Den stærkeste af dem alle. Definér din normal – fx „ordrer hver dag mellem 9 og 21“ – og reagér på afvigelsen. Ingen ordrer i seks timer på en normal hverdag skal udløse et tjek nu og ikke en undren i morgen.

Efter hver ændring på betalinger, fragt eller checkoutfelter gælder desuden minireglen fra opdateringspolitikken: kør nøglefunktionstesten med det samme, og notér ændringen i ændringsloggen.

Sæt tærsklerne ned på papir

En tørke-alarm virker kun, hvis tærsklen passer til jeres trafik. Tag udgangspunkt i de seneste måneders tal, og justér, når I lærer mønstrene at kende. Et eksempel på en lille webshop:

Funktion	Normal	Alarm ved	Første tjek
Kontaktformular	5–15 om ugen	0 i 5 dage	Testindsendelse, mailopsætning, gemte indsendelser
Ordrer	Dagligt i åbningstid	0 i 6 timer på en hverdag	Testkøb, gatewayens dashboard, ordrestatus
Ordremails	Én pr. ordre	Kunder spørger efter bekræftelse	Mail-log, spammappe, afsenderdomæne
Intern søgning	Resultater på kernevarer	0 resultater på en kendt vare	Søgeindeks, cache, seneste plugin-ændring

Tallene er eksempler – brug jeres egne. Er trafikken lav eller meget sæsonpræget, så sæt længere vinduer, så alarmen ikke bliver støj, som alle lærer at ignorere.

Søgning, mails og planlagte opgaver

Tre oversete funktioner med hver sin stille død.

Intern søgning

Søg hver måned på jeres tre vigtigste varer eller emner, og se, at der kommer resultater. Kig også i søgestatistikken efter hyppige søgninger uden resultat – de er både et fejlsignal og en ønskeliste.

Mails fra sitet

Ordrebekræftelser, bookingpåmindelser og kvitteringer sendes af systemet. Abonnér selv på dem – et testkøb og en testbooking dækker det – og reagér, hvis de udebliver eller lander i spam. Et mail-log-plugin gør det let at se, om WordPress overhovedet forsøgte at sende. Se WooCommerce sender ikke ordremails.

Planlagte opgaver (cron)

WordPress’ planlagte opgaver – udsendelser, synkroniseringer, oprydning – kører som standard via WP-Cron, der kun starter, når nogen besøger sitet. På et site med lidt trafik eller fuld sidecache kan opgaverne derfor blive forsinket eller springe over uden fejlbesked.

WooCommerce bruger desuden Action Scheduler til mange baggrundsopgaver. Under WooCommerce → Status finder du fanen med planlagte handlinger (Scheduled Actions), hvor du kan se, om der hober sig fejlede eller ventende handlinger op.

Halter udsendelser og synkroniseringer, så få sat en rigtig server-cron op, og slå den besøgsudløste cron fra i wp-config.php:

define( 'DISABLE_WP_CRON', true );

Server-cronjobbet kalder derefter WordPress med fast interval, fx hvert femte minut via WP-CLI:

*/5 * * * * cd /sti/til/site && wp cron event run --due-now > /dev/null 2>&1

Stien og muligheden for cronjobs afhænger af hostingen – spørg supporten, hvis du er i tvivl. Tjek listen over planlagte opgaver ved kvartalstjekket.

Stiger 404-fejlene pludselig i statistikken eller i serverloggen, hører det til samme kategori: et stille strukturskred, der skal spores til den ændring, der udløste det.

Automatisér det, der kan automatiseres

De månedlige test kan suppleres med automatik, når forretningen bærer det:

• Indholdstjek i oppetidsovervågningen: mange uptime-tjenester kan tjekke, at en bestemt tekst står på siden – fx at produktsiden viser „Læg i kurv“, eller at søgeresultatsiden viser en kendt vare. Så fanger overvågningen også en tom side, der svarer med status 200.
• Heartbeat-overvågning: et cronjob eller en automatisering „pinger“ en overvågningstjeneste, hver gang den har kørt. Udebliver pinget, kommer alarmen. Det er tørke-alarmen gjort automatisk.
• Syntetiske transaktioner: scriptede køb eller formularindsendelser på skema. Effektivt, men kræver vedligehold, og testordrer skal kunne skelnes fra rigtige.

Guiden om overvågning af automatiseringer går i dybden med heartbeat-mønsteret.

Sæt det i system

Funktionsovervågning skal ikke være et projekt. Det er fem faste elementer:

1. Månedens testindsendelse og testkøb i månedsrutinen.
2. Indsendelser gemt i databasen med en slettefrist.
3. Baseline og tørke-tærskler skrevet ned pr. funktion.
4. En aftalt modtager og reaktion – samme eskalationsvej som ved nedbrud.
5. To linjer i ændringsloggen, hver gang noget testes eller findes.

De fem elementer fanger langt de fleste stille fejl for en halv times indsats om måneden. Og test ændringer, før de rammer kunderne: et staging-miljø lader dig prøve plugin- og checkoutændringer af uden at røre den rigtige butik.

Læs også

• Hub: Driftshåndbogen
• Uptime-overvågning: værktøjer, intervaller og alarmer, der ikke larmer
• Testkøb før go-live: tjeklisten for hele betalingsflowet
• WooCommerce checkout virker ikke: diagnose fra browser til serverlog
• Loglæsning for ikke-teknikere: find svar i access- og fejllogs
• WooCommerce hosting hos Hostious – LiteSpeed, NVMe, daglig backup og staging fra Woo StartUp

Ofte stillede spørgsmål om funktionsovervågning

Hvorfor opdager uptime-overvågningen ikke disse fejl?

Fordi siden svarer normalt. Fejlen ligger i funktionen bag: mailen, betalingen eller søgningen. Oppetidsovervågning tjekker døren, funktionsovervågning tjekker, at butikken indenfor virker.

Hvor ofte skal vi teste formular og checkout?

Hver måned som fast rutine – og straks efter enhver ændring på betaling, fragt, formularer eller mailopsætning. Testen er bare at gøre det, kunden gør.

Hvad er en tørke-alarm?

En alarm på fravær: nul indsendelser eller ordrer i længere tid, end din normale baseline tilsiger. Den fanger stille fejl, længe før kunder eller regnskab gør.

Er et testkøb i gatewayens testtilstand nok?

Nej, ikke alene. Testtilstanden er god efter ændringer, men den prøver ikke den live-forbindelse, kunderne bruger. Lav også et rigtigt køb med et rigtigt kort hver måned, og refundér det bagefter.

Hvorfor kører planlagte opgaver ikke i WordPress?

WP-Cron starter kun ved besøg, så på sites med lidt trafik eller fuld sidecache kan opgaver blive forsinket. En rigtig server-cron, der kalder WordPress med fast interval, løser det typisk.