Fejlsporing i software: vælg mellem Airbrake, BugSnag, Rollbar og Sentry

En grøn hjemmeside kan stadig have fejl

Forsiden svarer, men en bestemt kunde kan ikke gemme sin ordre. En app åbner, men lukker ned, når brugeren vælger en bestemt funktion. Fejlsporing samler information fra den software, der faktisk kører, så udviklerne kan undersøge fejlens kode, kontekst og omfang.

Denne guide er til udviklingsansvarlige og softwareteams, der vil vælge et værktøj til fejl i applikationen. Den supplerer overvågning af oppetid og syntetiske brugerforløb. Et eksternt check fortæller, om det valgte forløb virker; instrumentering i applikationen kan give andre detaljer om de fejl, der opstår under rigtige kørsler. Ingen enkelt måling dækker automatisk begge behov.

Kort fortalt

Airbrake: Undersøg det, når teamet vil samle kodefejl og performance og have en eksplicit grænse for indsamlet forbrug.
BugSnag: Tag det med, når release-stabilitet, berørte brugere og forskelle mellem appversioner er centrale for prioriteringen.
Rollbar: Undersøg det, når fejlhændelser, browserforløb og længere historik skal indgå i samme undersøgelse.
Sentry: Start her, når fejlens kodekontekst skal forbindes med flere slags telemetri og en bredere udviklerarbejdsgang.

De fire er udvalgt som forskellige indgange til fejlundersøgelse. Vi har ikke udført en hastighedstest, målt hvor mange fejl de finder eller vurderet kvaliteten af deres AI-forslag.

Sammenligning af signal og forbrug

Stryg tabellen til siden for at se alle kolonner.

Tjeneste	Dokumenteret fokus	Prisdriver eller planvilkår	Prøve før køb
Airbrake	Kodenær fejlsporing og performance	Grundplan plus hændelser; usage cap kan stoppe modtagelse	En fejlstorm og virkningen af forbrugsgrænsen
BugSnag	Fejl prioriteret efter bruger- og releasepåvirkning	Fejlevents og performance-spans tælles separat	Samme fejl i to forskellige appversioner
Rollbar	Fejlgruppering, replays og releases	Occurrences, replays og credits; historik varierer med plan	En browserfejl med det forløb, der udløste den
Sentry	Kodekontekst, berørte brugere og release health	Separate kvoter for fejl, logs, spans og replays	En fejl, som skal følges gennem flere systemdele

En fejlhændelse er en observation, ikke nødvendigvis en unik fejl. Den samme kodefejl kan opstå mange gange, og derfor er antallet af fejltyper ikke tilstrækkeligt til at beregne forbruget.

Airbrake: forstå, hvad en hård grænse betyder

Airbrake beskriver SDK-baseret opsætning, løbende fejlalarmer og adgang til kodenær kontekst samt performanceovervågning. Et SDK er et kodebibliotek, som sættes ind i applikationen for at sende data til tjenesten. Det gør værktøjet relevant for et team, der vil begynde med fejl og svartid tæt på sin eksisterende kode. Produkt og opsætning

Prissiden beskriver Dev med én bruger, Basic med ubegrænsede brugere og tre teams samt Pro med ubegrænsede teams og auditlogs. Forbrug af fejl indgår særskilt. FAQ'en beskriver et usage cap: Sættes det til grundkvoten, stopper modtagelsen af yderligere fejl ved grænsen indtil næste periode. Siden viser også forskellige prisstrukturer i planfelter og FAQ, så et konkret samlet beløb bør bekræftes. Prisgrundlag og loft

Vores vurdering: Tag Airbrake med, hvis et enkelt afgrænset fejlspor og kontrol med forbrug er vigtigt. Sammenlign med Sentry, hvis flere typer telemetri skal kombineres. Afprøv både alarmen om højt forbrug og konsekvensen af loftet. En fast maksimalregning kan være et bevidst valg, men teamet skal vide, hvornår nye fejl ikke længere bliver modtaget.

BugSnag: prioriter efter stabilitet og påvirkning

BugSnag beskriver fejlovervågning med en indbakke ordnet efter alvor og brugerindvirkning samt data om stack traces, enheder og handlinger før fejlen. Platformen fremhæver også stabilitet på tværs af releases. Det er relevant, når udviklerne skal skelne mellem en udbredt fejl og en sjælden hændelse, der producerer mange gentagelser. Platform og fejlkontekst

Prissiden skelner mellem fejlevents og performance-spans. Free har én bruger, 7.500 events og en million spans om måneden. Select tilføjer blandt andet ubegrænsede brugere, mens Preferred fremhæver automatisk prioritering, stabilitetsbenchmarks og SAML. Enterprise tilføjer blandt andet automatisk fejlfordeling og særlige driftsmuligheder. De dynamiske beløb viste ikke et brugbart prisgrundlag; nulværdier i prisfelterne er ikke tolket som gratis betalte planer. Pakker og enheder

Vores vurdering: Undersøg BugSnag, når versioner og berørte brugere skal styre prioriteringen. Sammenlign med Rollbar på fejlkonteksten og med Sentry på det bredere undersøgelsesflow. Send en kendt testfejl fra to versionsnumre. Kontrollér, om teamet kan skelne en ny regression fra en gammel fejl, der stadig rammer brugere på en ældre version.

Rollbar: forbind fejlen med browserens forløb

Rollbar beskriver automatisk gruppering af lignende fejl, kodekontekst og forbindelse til versionsstyring. Session Replay kan vise et browserforløb ved siden af de relaterede fejl. Det er relevant, hvis en fejl er svær at forstå ud fra en stack trace alene, og udvikleren har brug for at se rækkefølgen af brugerens handlinger. Platform og undersøgelse

Free omfatter 5.000 occurrences og 1.000 replays om måneden. Essentials beskriver op til 90 dages historik og mere detaljerede hastighedsgrænser. Advanced udvider til op til 180 dage og tilføjer blandt andet adaptive alarmer, RQL/Metrics API og SCIM. Prisvælgeren har separate niveauer for occurrences, replays og credits; én planbetegnelse er derfor ikke et fuldt budget. Planer og kapacitet

Vores vurdering: Tag Rollbar med, når undersøgelsen ofte kræver et konkret browserforløb. Sammenlign med BugSnag på prioritering af appversioner og med Sentry på kobling til anden telemetri. Brug i piloten en formular med testdata og kontrollér, hvilke felter der vises i replay og fejlmetadata. Det er opsætningen, ikke alene produktnavnet, der afgør, hvad udviklerne modtager.

Sentry: flere datatyper kræver et samlet forbrugsblik

Sentry beskriver stack traces, handlinger før fejlen, berørte brugere, ejerskab og release health. Teamet kan dermed undersøge både, hvor i koden fejlen opstår, og om den hænger sammen med en udgivelse. Funktionernes værdi afhænger blandt andet af, om applikationen sender korrekt versions- og miljøinformation. Fejlmonitorering

Developer er begrænset til én bruger. Team har ubegrænsede brugere og API-/tredjepartsintegrationer; den viste grundkvote inkluderer 50.000 fejl. Logs, spans, replays og øvrige datatyper har deres egne kvoter og satser. Business tilføjer avanceret kvotestyring. Seer, platformens AI-debugger, står som en ekstra udgift og bør ikke antages inkluderet i et almindeligt Team-abonnement. Planer og beregner

Vores vurdering: Undersøg Sentry, når fejlsporing skal forbindes med flere typer data. Sammenlign med Airbrake, hvis behovet kan afgrænses til et enklere setup. Lav en prøve, hvor en frontendfejl hænger sammen med et fejlet kald til en backend. Kontrollér, hvilke sammenhænge I faktisk kan følge, og hvor der mangler instrumentering, før I konkluderer, at et bredere produkt automatisk giver et samlet billede.

Send fire kendte fejl gennem prøveopsætningen

Brug et testmiljø med en almindelig exception, en gentaget fejl, en fejl i en ny version og en håndteret fejl, som I selv vælger at rapportere. Lad to udviklere finde årsagen uafhængigt. De skal kunne se miljø, version og relevante spor uden at lede efter en anden persons lokale log.

Undersøg grupperingen: Bliver gentagelser samlet nyttigt, og kan to forskellige årsager komme til at ligne samme problem? Prøv derefter at rette fejlen og sende en regression. En alarm bør føre til en ansvarlig og en handling, ikke blot endnu en besked i en fælles kanal.

Budgettér med den dårlige dag

Forestil jer en fejl, der opstår 100 gange i minuttet i to timer. Det giver 12.000 hændelser fra én fejltype. Det er et regneeksempel, ikke en leverandørkvote. Læg jeres normale forbrug og eventuelle replays, logs eller spans til efter den enkelte tjenestes definitioner.

Beslut, hvordan teamet vil håndtere overforbrug: betale videre inden for et loft, filtrere kendt støj eller stoppe modtagelsen. Få virkningen demonstreret, og sørg for en alarm før den kritiske grænse. En lav abonnementspris uden forbrugsforståelse siger lidt om driften under en reel hændelse.

Hold data og arbejdsgang afgrænset

Kontrollér den faktiske payload fra prøveapplikationen. Fjern hemmeligheder og unødvendige personoplysninger fra fejlmetadata og eventuelle optagelser, og test at filtreringen virker. Aftal adgang og historik ud fra, hvor længe teamet behøver at undersøge en release.

Afslut med at oprette en fejl i jeres issue-system, rette den og følge den tilbage til overvågningen. Vælg den tjeneste, hvor teamet kan omsætte signalet til en forklarlig rettelse, og hvor pris, datamængde og ejerskab er tydelige, før den første fejlstorm rammer.

Metode og kilder

Udvalget belyser forskellige relevante arbejdsgange og er ikke en komplet markedsoversigt. Leverandørerne står alfabetisk. Produktfakta kommer fra leverandørernes egne sider; anbefalinger, eksempler og forslag til afprøvning er redaktionelle vurderinger. Vi har ikke udført produkttest eller indhentet tilbud. Dansk support og aftalevilkår for jeres konkrete installation er ikke verificeret.

Kilder kontrolleret 23. september 2026. Publicerings- og ændringsdato er ikke entydigt oplyst for alle kilder; kontroldatoen er vores læsedato. Planer og priser kan ændre sig. Kommercielle relationer mellem Branchekompas/Carter & Co og leverandørerne er uafklarede; vi fremsætter ingen erklæring om dokumenteret økonomisk uafhængighed.

Relaterede guider

Se oppetid og syntetisk overvågning for eksterne checks og feature flags for kontrolleret aktivering af ændringer.