Så bygger du en statussida: komponenter, incidenter och upptidskontroller

En statussida talar om för dina användare, på ett och samma ställe, om din tjänst fungerar. För att bygga en behöver du en lista över komponenter (webbplats, API, betalningar, e-postutskick), en aktuell status för varje komponent, incidenter med tidsstämplade uppdateringar, en historik över tidigare incidenter och eventuellt prenumerationer så att folk får veta om problem utan att behöva kolla själva. Sidan i sig är enkel. Det viktiga beslutet är var den körs: en statussida måste vara uppe när din app är nere, så den bör inte dela hosting, databas eller driftsättningsflöde med det den rapporterar om.

Vad en statussida är till för

När något går sönder vill användarna veta tre saker: är det bara jag, vet ni om det, och när blir det åtgärdat. En statussida svarar på alla tre utan att översvämma supporten med ärenden. Den bygger också förtroende över tid, eftersom en synlig incidenthistorik med ärliga redogörelser visar hur du hanterar problem.

Det är inte en ändringslogg. Nya funktioner hör hemma på en ändringsloggsida; driftstopp och underhåll hör hemma här.

Vad sidan behöver

Data

Komponentstatus är vanligtvis en kort fast lista: Fungerar, Försämrad prestanda, Delvist driftstopp, Större driftstopp, Under underhåll.

Sidor

• Publik statussida: en övergripande banner (”Alla system fungerar” eller den värsta aktuella statusen), varje komponent med sin status, eventuella aktiva incidenter med uppdateringar, kommande underhåll och en 90-dagars historikremsa om du har kontrolldata.
• Incidentsida: fullständig tidslinje av uppdateringar för en incident, med egen URL så att supporten kan länka dit.
• Historik: tidigare incidenter per månad.
• Prenumerera: e-postregistrering med bekräftelse och inställningar per komponent.
• Admin: skapa incident, publicera uppdateringar, ändra komponentstatus, schemalägg underhåll.

Behörigheter

Allmänheten ser allt som publicerats. Bara ditt team kan publicera. Håll admininloggningen separat från din appers inloggningssystem om du kan, så att ett avbrott hos din autentiseringsleverantör inte låser ute dig från din egen statussida.

Det viktigaste beslutet: håll den oberoende

Här brukar hemmabyggda statussidor misslyckas. Om din statussida:

• körs på samma server eller hostingkonto som din app,
• läser från samma databas,
• sitter bakom samma domäninställning eller CDN-konfiguration,
• eller driftsätts via samma pipeline,

kommer många driftstopp att ta ner den också, precis när folk behöver den. Praktiska steg:

• Separat hosting. Ett annat projekt eller en annan leverantör än huvudappen.
• Egen subdomän, som status.exempel.se, pekad separat i DNS. Se så fungerar domäner och DNS.
• Egen data. Incidenter lagras i statussidans egen lagring, inte i din appdatabas.
• En statisk reservlösning. Vissa team gör den publika sidan statisk och bygger om den vid varje uppdatering, så det finns nästan inget som kan gå sönder.

Manuella uppdateringar eller automatiska kontroller

Manuellt (börja här)

Ditt team skriver incidenter och ändrar komponentstatus för hand från adminsidan. Så fungerar många statussidor i praktiken, eftersom en mänsklig bedömning (”betalningarna är långsamma för vissa kortyper”) är mer användbar än en automatisk röd prick.

För att snabbt få veta om problem, använd en extern uptime-övervakning som kontrollerar din app ungefär varje minut och larmar dig via e-post, SMS eller chatt. Många övervakningstjänster har kostnadsfria nivåer.

Automatiskt

Automatisering innebär att något regelbundet kontrollerar varje komponent och uppdaterar dess status. Det kräver kod som körs enligt schema, utanför din huvudapps infrastruktur. Två vanliga mönster:

• En extern övervakning anropar din statussida via en webhook när en kontroll misslyckas eller återhämtar sig, och statussidan uppdaterar komponenten.
• Ett schemalagt jobb i statussidans egen hosting pingar varje komponent och sparar resultatet. Kontrollera hur din hosting hanterar schemalagda uppgifter innan du förlitar dig på det; vår guide om bakgrundsjobb förklarar alternativen.

Automatiska ändringar kan fladdra (upp, ner, upp) vid ett långsamt nätverk. Kräv två eller tre misslyckade kontroller innan en status ändras, och låt en människa bekräfta innan ett större driftstopp meddelas.

Skriva incidentuppdateringar

• Publicera tidigt. ”Vi undersöker rapporter om misslyckade inloggningar” inom några minuter slår ett perfekt meddelande en timme senare.
• Säg vad användarna märker, inte vad som gick sönder internt.
• Lova tidpunkten för nästa uppdatering, och håll den.
• Avsluta med en kort sammanfattning när det är åtgärdat: vad som hände, hur länge och vad du ändrar.

En första prompt som fungerar

Bygg en fristående statussida för vår app Parcelio, som ska hostas separat på status.parcelio.com. Komponenter: Webbplats, Spårnings-API, Notiser, Betalningar, var och en med status Fungerar, Försämrad prestanda, Delvist driftstopp, Större driftstopp eller Under underhåll. Den publika sidan visar en övergripande banner med den värsta aktuella statusen, varje komponent med sin status, aktiva incidenter med tidsstämplade uppdateringar, nyast först, kommande underhåll och en lista över tidigare incidenter per månad. Varje incident har en egen sida. Lägg till en lösenordsskyddad adminsida för att skapa incidenter (titel, påverkan, berörda komponenter), publicera uppdateringar (meddelande och status: Undersöker, Identifierad, Övervakar, Åtgärdad), ändra komponentstatus och schemalägga underhåll. Lägg till en endpoint POST /api/check-result som tar emot ett komponentnamn och upp/ner från en extern övervakning, skyddad med en hemlig token, och som markerar en komponent som Försämrad först efter tre nedgångar i rad. Spara allt i den här appens egna databas. Enkel, lugn design som laddar snabbt i mobilen.

Byggsteg

1. Publik sida och admin med manuella incidenter. Detta ensamt är en fungerande statussida.
2. Hosta den separat och peka en subdomän mot den.
3. Incidentsidor och historik.
4. Underhållsfönster.
5. Prenumerationer. Registrering med dubbel bekräftelse via e-post och aviseringar vid nya incidenter och uppdateringar. E-post kräver en leverantör; se så skickar du e-post från din app.
6. Övervakningswebhook om du vill ha automatiska statusändringar.
7. Kör en övning. Skapa en påhittad incident, publicera uppdateringar, åtgärda den, kontrollera e-postmeddelandena och ta sedan bort den.

Vanliga misstag

• Hosta den tillsammans med appen. Det vanligaste och allvarligaste misstaget.
• En sida som alltid säger ”Alla system fungerar”. Om den aldrig visar problem slutar användarna lita på den.
• Inga tidsstämplar eller tidszon. Visa alltid tider med zon.
• Att förlita sig på huvudappens inloggning för adminsidan.
• Tystnad mellan uppdateringar. ”Inga nyheter, vi arbetar fortfarande på det” är en giltig uppdatering.
• Fladdrande automatiska statusar. Kräv upprepade misslyckanden innan en ändring sker.

När en färdig statussidestjänst är bättre

Tjänster för statussidor är byggda kring oberoendeproblemet: de körs på separat infrastruktur, hanterar prenumerantaviseringar via e-post och sms och innehåller ofta övervakning och integrationer med incidentverktyg. Om drifttillgänglighet är något dina kunder betalar för, eller om du har avtalsenliga skyldigheter att rapportera incidenter, är en dedikerad tjänst oftast värd pengarna. Många har kostnadsfria eller billiga nivåer för små team, så kolla innan du bygger själv.

Bygg själv när du vill ha full kontroll över design och formuleringar, när dina behov är enkla (några få komponenter, manuella uppdateringar) eller när en statussida är en del av en produkt du bygger för andra.

Bygga den med Mythex

På Mythex kan du bygga statussidan som ett eget projekt, skilt från huvudappen, vilket ger separat hosting och egen databas. Beskriv den i chatten, kontrollera den i förhandsvisningen, publicera den och koppla sedan en subdomän som status.dindomän.se (egna domäner ingår i Pro). Tänk på att publicerade Mythex-appar och deras databaser vilar när de inte används och vaknar vid nästa besök, så första laddningen efter en lugn period kan ta längre tid. En enkel, lätt sida hjälper.

Mythex dokumenterar inte schemalagda jobb, så för automatiska kontroller använd en extern uptime-övervakning som anropar en webhook-endpoint i din statussida (se webhook-receptet). E-postaviseringar till prenumeranter går via din egen leverantör, med nyckeln lagrad som projekthemlighet (recept för att skicka e-post).

Frågor