# Incidentrespons bästa praxis: vad solo-devs behöver URL: https://whatshouldibuildnext.com/sv/journal/basta-praxis-for-incidentrespons Type: blog Locale: sv Published: 2026-08-29 Updated: 2026-08-31 --- > Guider om incidentrespons skrivs för enterprise-team, inte för dig som bygger solo. Här är vad som faktiskt krävs: larm som håller, runbooks du faktiskt använder, och en statussida du äger. ## Bästa praxis för incidentrespons: vad som faktiskt funkar för dig som bygger solo Bästa praxis för incidentrespons skrivs för enterprise-team, inte för devs som bygger solo. Du skickar ett sidoprojekt, det hittar användare, och en morgon twittrar någon att det har legat nere i tre timmar. Du visste inte om det. Inga larm. Ingen runbook. Ingen statussida. Det är det verkliga haveriet för 90 % av solo-byggda produkter. Det kräver inte ett 40-sidigt playbook eller ett enterprise-verktygsstack. Det kräver tre saker: veta när något gick sönder, veta vad man ska göra åt det, och kommunicera status till alla som bryr sig. Den här guiden täcker varje del ur ett builders perspektiv, inklusive vad du ska bygga själv och vad du kan sy ihop från befintliga verktyg. ## Vad som havererar först när du är solo och jour Den första incidenten du hanterar solo spenderar du 12 minuter på att lista ut var saker finns, innan du spenderar 4 minuter på att faktiskt fixa det. Det är den verkliga kostnaden. Inte driftstoppet. Den koordinationsoverhead som ett en-persons-team har när inget är nedskrivet. Var finns miljövariablerna? Vilken tjänst havererar egentligen? Påverkar det alla användare eller bara en kund? Du tillbringar det gyllene fönstret av en incident med att söka efter svar som du borde ha förberett. Lösningen är inte komplexa verktyg. Det är att ha svarat på de frågorna innan kl 3 på natten. Det finns ett nyttigt test: föreställ dig att ditt produktions-API går ner just nu. Du har 10 minuter. Kan du hitta relevanta loggar, identifiera den havererade komponenten och rulla tillbaka eller hotfixa utan att öppna mer än två flikar du inte redan hade öppna? Om svaret är nej är det precis det som incidentrespons löser. ![Solo-dev vid skrivbordet sent på natten med telefon som visar flera larmnotiser och serverövervakning på laptop-skärm](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/whatshouldibuildnext/2026-08/2586d5-inline1.webp) ## Tre saker varje indie-setup faktiskt behöver Innan du bygger något, namnge vad systemet måste göra: - **Upptäcka problemet** innan en användare DM:ar dig om det - **Berätta vad du ska göra** när du är halvt vaken och bara har kontexten från larmet - **Berätta för dina användare** vad som händer utan att förvärra situationen Varje incidentrespons-verktyg, från PagerDuty till ditt eget cron-jobb, mappar till ett av dessa tre jobb. Bygg den enklaste versionen som klarar alla tre, och sluta sedan. Frestelsen är att bygga mot enterprise-versionen: jourscheman, eskaleringspolicys, allvarlighetsnivåer P0 till P5, postmortem-mallar. Det är lämpligt vid 20 ingenjörer och 500 000 användare. Vid en dev och 500 användare bränner de abstraktionerna dina helger och förblir oanvända. Den minimala versionen är genomförbar den här helgen. Skicka det först. ## Bygg ditt larmlager: det falska larmet är första hindret Varje dev som har byggt sitt eget larmsystem har samma historia: den första regeln de skrev var fel, och de stängde av pagern efter två veckor med brus. Börja med en kontroll som spelar roll. En havererad health check-endpoint räcker. `# Enkel health check-endpoint (Express/Node) app.get('/health', (req, res) => { res.json({ status: 'ok', timestamp: Date.now() }); });`Koppla sedan ett cron-jobb för att pinga den var 60:e sekund. Om det misslyckas tre gånger i rad får du ett SMS. Det är ditt första larmlager. Det fångar 80 % av de incidenter som påverkar användare. Andelen falska positiva i den här setuppet är nära noll. Du larmas när tjänsten faktiskt är nere, inte när en CPU-topp utlöste ett tröskelvärde som aldrig kalibrerades. Det är det svåraste att få rätt i larmning: larmet måste vara sant varje gång, annars tränar du dig själv att ignorera det. Loggbaserad larmning kommer efter att driftstoppskontrollen fungerar och är betrodd. För självhostade stackar hanterar Grafana det här väl till lägre kostnad. Datadog börjar ge mening när du hanterar mer än två eller tre tjänster och vill ha en enhetlig vy med enkel integration till din deployment-pipeline. ## En runbook är dokumentet du skriver kl 23 för att läsa kl 3 En runbook är inte dokumentation. Dokumentation förklarar hur något fungerar. En runbook berättar för en framtida version av dig, stressad, knappt vaken och under press, exakt vad du ska göra just nu. Formatet som funkar för solo-projekt: - **Vad är sönder?** En mening, bara observerbara symptom - **Är det brådskande?** Påverkar det betalande kunder just nu? - **Vad gör jag?** Tre till fem numrerade steg, börja med det snabbaste att prova Det är det. Skriv det när du inte är mitt i en incident. Gå igenom och uppdatera det efter en incident för att se om det faktiskt var användbart. Var du lagrar runbooks spelar mindre roll än vanan att skriva dem. En Notion-sida, en Markdown-fil i ditt repo, ett delat dokument. Testet: kan du öppna det på din telefon på 30 sekunder, halvt vaken, kl 3 på natten? Det praktiska argumentet för Notion framför en repo-fil är mobil åtkomst. Om du sover bredvid din telefon för att du har produktionstrafik och en dålig känsla om ett deploy du just skickade spelar det roll. GitBook är ett annat solitt alternativ om du föredrar något mer strukturerat som också dubblar som publik developer-dokumentation. ![Dev-skrivbord med öppen anteckningsbok som visar ett incidentrespons-beslutsflödesschema, laptopterminal och klisterlappar med diagram](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/whatshouldibuildnext/2026-08/4f1cbf-inline2.webp) ## En publik statussida: vad dina användare faktiskt vill veta när det krånglar Dina användare behöver inte en realtids-observabilitets-dashboard. De behöver veta två saker: är det sönder för alla, och är du medveten om det? Den minimalt livskraftiga statussidan har tre element: - En statusindikator med högst tre tillstånd: driftsatt, nedsatt, nere - En tidsstämpel för när det aktuella tillståndet senast uppdaterades - En rad med enkel text när något är fel Användare som kollar en statussida under en incident läser inte arkitekturdiagram. De vill sluta felsöka sin egen setup för att de nu vet att det inte är deras fel. Att bygga det tar under fyra timmar: - En statisk HTML-sida med ett JavaScript-kodstycke som hämtar status från en endpoint - En Supabase-tabell med två fält: status (enum) och meddelande (text) - Ett cron-jobb som uppdaterar status baserat på ditt health check-resultat - En admin-endpoint bakom autentisering för att skriva ett manuellt meddelande vid behov Det svåra är inte bygget. Det är vanan att uppdatera det under en incident istället för att dyka direkt in i fixen. Uppdateringen tar 30 sekunder och sparar 15 kundsupport-mejl. Det andra argumentet för att bygga det själv: kommersiella statussida-verktyg tar $30 till $100 per månad för vad som i grunden är en JSON-endpoint och en statisk HTML-sida. Bygg det en gång, äg det. Dina användare behöver inte Statuspage.io. De behöver en URL som fortfarande fungerar när din huvuddomän går ner. ![Statussida-dashboard som visar tjänstehälsoindikatorer med gröna och gula statusdottar och drifttidsgraf på mörkt UI](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/whatshouldibuildnext/2026-08/dd8fe9-inline3.webp) ## Postmortem när du är den enda att skylla på Postmortems i enterprise-sammanhang handlar om att inte skylla på individer och identifiera systemiska fel. Solo är du systemet. Psykologin är annorlunda, men praktiken spelar fortfarande roll. Anledningen att skriva postmortems ensam: du kommer att lösa samma klass av problem två gånger om du inte gör det. Tre månader senare tittar du på en databasfråga som låste sig på grund av ett index du inte lade till, och du har ett vagt minne av att ha fixat något liknande förut, men minns inte vad. Ett fem-minuters format som håller: - Vad hände (ett stycke, bara fakta, inget skuldspråk) - Vad du gjorde för att fixa det - En sak att ändra i systemet - En sak att ändra i din process Skriv det på samma ställe som dina runbooks. Det blir indata för nästa runbook-uppdatering. Över sex månader skapar det en lättviktig förteckning över ditt systems haverilägen som inget enterprise-postmortem-verktyg replikerar för en solo-builder. ## Ska du bygga det själv eller sy ihop befintliga verktyg? Det ärliga svaret beror på var du befinner dig. Om du har noll betalande kunder: bygg hela grejen själv. Health check-cron, statussida, Notion-runbooks. Det här är rätt projekt för att lära sig mönstren. Det shipper på en helg. Det lär dig vad incidentrespons faktiskt kräver. Och om du bestämmer dig för att senare bygga och sälja det som en produkt har du validerat kraven på dig själv först. Om du har betalande kunder som är beroende av drifttid idag: börja med befintliga verktyg. Koppla Grafana Cloud free tier, sätt upp en driftstoppsmonitor och öppna en Notion-runbook-sida den här eftermiddagen. Du behöver täckning nu, inte efter tre helgers byggande. Den del som är värd att bygga själv oavsett fas: statussidan. Äg den, hosta den på en separat domän, bygg den den här helgen. Allt annat kan du sy ihop från befintliga free tiers tills komplexiteten motiverar att bygga det. ## Det gap som ingen incidentrespons-guide talar om Problemet är inte verktygen. Det är de 48 timmarna mellan 'jag borde sätta upp larmning' och 'jag satte faktiskt upp larmning.' De flesta solo-dev-stackar har tillräckliga observabilitets-primitiver för att bygga ett första incidentrespons-lager på en enda dag. Health check-endpoint finns någonstans. Loggarna finns någonstans. Deploy-pipelinen har viss felhantering. Det som saknas är 90 minuters fokuserad koppling: health check till driftstoppsmonitor, driftstoppsmonitor till SMS eller Telegram-larm, en Notion-sida med tre runbooks, statisk sida med en Supabase-statusendpoint. Det här är inte projektet du skickar till användare. Det är projektet du skickar för dig själv. Bygg det den här helgen. Första gången något går sönder kl 3 på natten och du spenderar 4 minuter på att fixa det istället för 40 minuter på att hitta det, förstår du varför bästa praxis för incidentrespons finns till. Inte för att enterprise-team beordrade det, utan för att alternativet är sämre. ## FAQ ### Vad är det minsta en solo-dev behöver för incidentrespons? Tre saker: ett larmlager som ger dig ett SMS när tjänsten är nere (börja med en health check-endpoint och ett cron-jobb), runbooks med steg-för-steg-instruktioner för de vanligaste haverierna, och en statussida som kommunicerar status till dina användare. Allt detta är genomförbart på en helg. ### Hur undviker man falska larm i ett hemgjort larmsystem? Börja med en enda kontroll: en health check-endpoint som pingas var 60:e sekund. Larm bara när den misslyckas tre gånger i rad. Den här setuppens andel falska positiva är nära noll. Lägg till fler kontroller och loggbaserad larmning först när den grundläggande driftstoppskontrollen är betrodd. ### Varför bör statussidan hostas på en separat domän? Om din huvuddomän går ner är statussidan också otillgänglig om den hostas på samma ställe. Hosta den på en separat domän och en annan infrastruktur så att den fortfarande fungerar när din huvudapplikation är nere. Det är också den dag dina användare faktiskt behöver den. ### Vad ska en runbook innehålla för ett solo-projekt? Tre delar: vad som är sönder (observerbara symptom i en mening), om det är brådskande (påverkar det betalande kunder just nu?), och vad du ska göra (tre till fem numrerade steg, börja med det snabbaste att prova). Ingen dokumentation om hur systemet fungerar. Bara vad du ska göra nu. ### När är Datadog värt kostnaden för en indie hacker? Datadog börjar ge mening när du hanterar mer än två eller tre tjänster och vill ha en enhetlig vy med enkel integration till din deployment-pipeline. Innan dess hanterar Grafana det här väl till lägre kostnad. Med en enda tjänst och 500 användare börja med Grafana Cloud free tier. ### Hur skriver man en postmortem när man är soloutvecklare? Använd ett fem-minuters format: vad hände (ett stycke, bara fakta), vad du gjorde för att fixa det, en sak att ändra i systemet, och en sak att ändra i din process. Skriv det på samma ställe som dina runbooks. Över tid skapar det en lättviktig förteckning över ditt systems haverilägen. ### Är det värt att bygga incidentrespons-verktyg som en produkt? Om du har noll betalande kunder är det ett utmärkt projekt att bygga för dig själv: det shipper på en helg, du lär dig mönstren, och du validerar kraven på dig själv. Kommersiella statussida-verktyg tar $30 till $100 per månad för vad som är en JSON-endpoint och en statisk HTML-sida. Det ekonomiska argumentet för att bygga det själv är starkt.