Driftstörningen den 23 juni 2026 – vad som hände och vad vi gör åt det

Tisdagen den 23 juni 2026 drabbades sajn av en driftstörning som påverkade hur snabbt dokument skickades ut, hur signeringar behandlades och hur försegling och notiser levererades. Eftersom transparens är en av våra viktigaste principer vill vi berätta exakt vad som hände, vad det betydde för dig som använder sajn och – framför allt – vad vi gör för att det inte ska hända igen.

Det viktigaste först: Ingen data gick förlorad. Alla signaturer fångades. Inget dokument tappades bort och inget jobb misslyckades. Allt som skulle hända hände – men under några timmar mitt på dagen blev det kraftigt försenat innan det till slut gick igenom.

Vad hände?

Stora delar av vår bakgrundsbearbetning – utskick av dokument, insamling av BankID-signaturer, försegling, notismejl och webhooks till era integrationer – körs som schemalagda jobb via vår leverantör Trigger.dev. Den 22–23 juni drabbades Trigger.dev av en allvarlig infrastrukturincident i sin molnplattform. Kortfattat överbelastades deras Kubernetes-styrning när en stor mängd servrar anslöt samtidigt som timvisa jobb startade, vilket fick deras interna koordineringsdatabas (etcd) att tappa kvorum. Resultatet blev att nya jobb inte kunde tilldelas körningsutrymme.

Trigger.dev har själva publicerat en utförlig incidentrapport: trigger.dev/blog/incident-report-jun-22-2026.

Incidenten började i deras primära region och spred sig sedan till den europeiska region (eu-central-1, Frankfurt) där våra bakgrundsjobb körs. Värt att vara tydlig med: detta är fortfarande inom EU. Vår egen infrastruktur ligger i eu-north-1 (Stockholm), och Trigger.dev kör våra jobb i eu-central-1 – båda inom unionen. Den europeiska regionen klarade sig genom natten, men runt klockan 11 på förmiddagen den 23 juni slutade våra jobb att startas.

Varför larmade inte våra system direkt?

Det här är den obekväma men ärliga delen, och den lärdom vi tar med oss tydligast.

Vi har sedan länge skyddsnät för när jobb misslyckas – automatisk failover, larm till vår jour och uppdateringar till vår statussida. Problemet den här gången var att inget jobb misslyckades. Jobben fastnade bara i kö och väntade. Ur systemets perspektiv såg allt "friskt" ut – jobben fanns kvar, de hade inte fått något fel, de bara startade aldrig.

För att sätta det i perspektiv: under normal drift startar ett bakgrundsjobb hos oss på under en sekund (i hälften av fallen runt 0,3 sekunder, och nästan alltid inom 3 sekunder). Under incidenten växte den tiden till upp emot fem timmar för de värst drabbade jobben. Men eftersom våra larm var byggda kring fel – inte kring fördröjning – fångade de aldrig att kötiden skenade.

Tidslinje (svensk tid)

• Fram till ca 10:55 – Allt fungerade normalt. Jobb startade direkt, på bråkdelar av en sekund.
• Ca 11:00 – Bearbetningen frös. Det sista jobbet som startade i tid gjorde det 10:54; nästa jobb fastnade i kö och blev stående.
• 11:00–16:00 – I praktiken stod hela vår bakgrundsbearbetning stilla. Varje nytt jobb som skapades – dokument som skickades, signaturer som lämnades, webhooks som utlöstes – togs emot och registrerades, men blev stående i kö i stället för att köras. Hundratals jobb hopade sig under perioden.
• Ca 16:00 – Trigger.dev återställde kapaciteten och kön började beta av sig. Jobben kördes nu, i tur och ordning.
• Ca 16:00–17:30 – Eftersläpningen arbetades igenom. Under en kort period uppstod en sekundär kö när uppdämda och nya jobb konkurrerade om utrymmet, men kötiderna sjönk stadigt.
• Ca 17:30 – Tillbaka till normala kötider (under ett par sekunder). Helt utstädat under kvällen.

Den sammanlagda störningen varade alltså i runt sex och en halv timme, varav cirka fem timmar med i praktiken fryst bearbetning.

Vad innebar det här för dig som kund?

Under störningen kunde du uppleva att:

• Dokument du skickade inte nådde mottagaren direkt, utan med fördröjning.
• En signering du genomförde inte verkade "gå vidare" – bekräftelser, förseglade dokument och notiser dröjde.
• Webhooks till dina integrationer (CRM, affärssystem och liknande) kom fram senare än vanligt.

Vi förstår att det här skapade osäkerhet, särskilt mitt i en arbetsdag. Men det är viktigt att vara tydlig med vad som inte hände:

Ingen data gick förlorad. Varenda signatur som lämnades under störningen fångades och behandlades korrekt – bara med fördröjning. Inget dokument försvann och ingen signering behövde göras om manuellt. Varje enskilt fördröjt jobb slutfördes i sin helhet så fort kapaciteten kom tillbaka – de som behövde köras om kördes om automatiskt, utan att något gick förlorat. Det enda som faktiskt förlorades var tid.

Varför flyttade vi inte bara över till en annan region?

En berättigad fråga är: om Trigger.dev fick tillbaka kapacitet snabbare i sina amerikanska regioner – varför flyttade ni inte bara körningen dit? Den snabbaste vägen tillbaka hade onekligen varit just det. För oss var det inte ett alternativ.

All vår infrastruktur ligger primärt i eu-north-1 (Stockholm), och all behandling av personuppgifter och dokument sker inom EU. Det är ett medvetet och hårt hållet val av GDPR- och efterlevnadsskäl – vi gör aldrig avkall på var data får befinna sig, inte ens tillfälligt under en pågående incident. Att flytta bearbetningen till en server i USA för att komma igång snabbare hade brutit mot exakt de garantier våra kunder förlitar sig på. Det var ett solklart nej för oss – även om det i just det här fallet gjorde oss mer sårbara för själva fördröjningen.

Till det kommer att vi ansluter till Trigger.dev via AWS PrivateLink rakt in i vårt eget VPC, så att trafiken aldrig lämnar vår privata nätverksmiljö ut på publika internet. Det är starkt ur säkerhetssynpunkt – men det betyder också att en snabb omdirigering till en annan region inte är något vi kan göra säkert på studs, utan att tumma på just den nätverksisolering vi byggt in.

Kort sagt: våra säkerhets- och efterlevnadsval gjorde oss mindre flexibla i stunden. Det är en avvägning vi står för till hundra procent – vi väljer hellre att vänta än att flytta känsliga data ut ur EU. Men det innebär också att rätt lösning för oss måste vara en egen, EU-baserad reserv, inte en snabb flytt till någon annans server på andra sidan Atlanten.

Vad vi gör åt det

En leverantörsincident vi inte kunde förhindra är ändå vårt ansvar gentemot er. Här är de konkreta åtgärder vi vidtar:

1. Larm på kötid, inte bara på fel. Det här är den enskilt viktigaste lärdomen. Vi inför övervakning som larmar på fördröjning. Eftersom ett jobb normalt startar på under en sekund (och så gott som alltid inom 3 sekunder) sätter vi larmtrösklar långt under den nivå vi såg i incidenten – så att vi blir varse en skenande kö inom minuter i stället för efter timmar. Vi mäter nu aktivt tiden från att ett jobb skapas till att det faktiskt börjar köras, och slår larm om den tiden överskrider en bråkdel av det normala.

2. Tydligare och tidigare information till dig som kund. Vår statussida och våra utskick ska spegla förseningar och inte bara hårda avbrott. Om bearbetningen släpar efter ska du få veta det direkt, med en uppdatering om vad det innebär och när vi förväntar oss att vara ikapp – inte i efterhand.

3. Ett eget reservsystem för de kritiska stegen. Redan idag driftsätter vi ett första, mindre internt "Trigger-alternativ" som körs i vår egen EU-baserade infrastruktur och kan ta över de mest affärskritiska jobben – generering och utskick av dokument, försegling och webhooks – när vår primära leverantör inte levererar i tid. Det är medvetet enklare och långsammare än normal drift, men målet är glasklart: att även i värsta tänkbara läge behandla allt inom minuter i stället för timmar. Eftersom reserven ligger inom EU finns ingen konflikt med våra efterlevnadskrav. Det här första steget är bara början – den större, fullständiga redundansen är en tyngre infrastruktursatsning som vi gör till vår högsta prioritet under de kommande dagarna och veckorna.

4. Vi ser över alternativ till Trigger.dev. Trigger.dev har varit en bra leverantör och har hanterat den här incidenten öppet och ansvarsfullt. Men en störning som den här visar risken i att förlita sig på en enda part för både schemaläggning och redundans. Vi utvärderar nu alternativ och en mer leverantörsoberoende arkitektur – alltid inom EU – så att vi inte är beroende av att någon annans infrastruktur alltid är uppe.

Avslutningsvis

Den absolut viktigaste poängen tål att upprepas: ingen data gick förlorad, alla signaturer fångades, och allt slutfördes till slut – det blev bara en lång fördröjning på vägen. De avtal och signaturer som hanterades den 23 juni är lika giltiga och kompletta som vilken annan dag som helst.

Det som gick fel på vår sida var inte att vi inte hade skyddsnät – utan att våra skyddsnät var byggda för fel, inte för fördröjning. Den blinda fläcken stänger vi nu igen. Och vi tar med oss den större lärdomen: att inte luta hela kedjan mot en enda leverantör.

Tack för ditt tålamod den här dagen. Har du frågor om hur just dina dokument påverkades är du varmt välkommen att höra av dig, så går vi igenom det tillsammans.

//Teamet på sajn