Vad är uptime-monitoring? Grunderna för att hålla din tjänst online

Uptime-monitoring innebär att ett externt system regelbundet kontrollerar att din webbsida, ditt API eller din server svarar som förväntat — och skickar ett larm så fort den inte gör det. Målet är enkelt: du ska veta om något är fel innan dina kunder gör det.

Grundprincipen: kontrollera, jämför, larma

En uptime-monitor följer samma grundmönster oavsett vad den övervakar:

1. Kontrollera — skicka ett anrop till målet med jämna mellanrum, till exempel var femte minut.
2. Jämför — matcha svaret mot vad som förväntas: rätt statuskod, ett svar inom tidsgränsen, ibland ett specifikt innehåll.
3. Larma — om svaret avviker, meddela direkt via e-post, SMS, Slack eller webhook.

Skillnaden mellan olika monitoringlösningar ligger mest i hur sofistikerad steg två är, och hur snabbt och flexibelt steg tre går att konfigurera.

Vanliga typer av kontroller

HTTP/HTTPS-kontroll. Den vanligaste typen — ett anrop till en URL som kontrollerar statuskod och svarstid. Grundläggande, men fångar de flesta driftstopp.

Keyword-kontroll. En variant av HTTP-kontrollen som också letar efter ett specifikt textstycke i svaret. Praktiskt eftersom en server kan svara med statuskod 200 samtidigt som sidan bakom är trasig — till exempel visar ett felmeddelande eller en tom sida efter ett bakomliggande databasfel. Statuskoden ser frisk ut; innehållet gör det inte.

Ping-kontroll. Kontrollerar bara att servern är nåbar på nätverksnivå, utan att bry sig om vad som körs på den. Snabbt men grovt.

Port-kontroll. Kontrollerar att en specifik tjänst lyssnar på en specifik port — vanligt för att övervaka databaser, mejlservrar eller andra tjänster som inte pratar HTTP (till exempel SMTP, FTP eller SSH).

SSL-certifikatkontroll. Varnar innan ett certifikat går ut, snarare än efter att webbläsare redan börjat visa säkerhetsvarningar för besökarna.

Cron- och heartbeat-kontroll. För jobb som körs periodiskt istället för att svara på förfrågningar krävs ett annat mönster — heartbeat-monitoring, där jobbet själv rapporterar att det körts, istället för att någon frågar om det.

Kontrollintervall och svarstid

Hur ofta en tjänst kontrolleras är en avvägning mellan hur snabbt du vill upptäcka problem och hur mycket belastning kontrollerna själva lägger på tjänsten. Var femte minut är ett vanligt standardintervall för de flesta webbsidor och API:er. Mer kritiska tjänster — betalflöden, inloggning — kontrolleras ofta tätare, ibland ned mot var 30:e sekund.

Svarstid (hur lång tid det tar för tjänsten att svara) är en egen mätpunkt utöver bara upp/ner. En tjänst som svarar, men allt långsammare, är ofta ett tidigt varningstecken för problem som ännu inte blivit ett fullständigt driftstopp.

Vad "uptime" faktiskt mäter

Uptime uttrycks vanligen i procent över en tidsperiod — 99,9 % uptime under en månad betyder att tjänsten var otillgänglig i som mest cirka 43 minuter den månaden. Ju fler nior, desto mindre tillåten stilleståndstid:

Uptime	Max nedtid per månad
99 %	~7 timmar 18 minuter
99,9 %	~43 minuter
99,99 %	~4 minuter 20 sekunder

Ett SLA (Service Level Agreement) är det avtalade löftet om vilken uptime som ska levereras. Uptime i sig är mätningen — den faktiska historiken av upp och ner. SLA:t är löftet mätningen hålls mot.

Larm som faktiskt når fram

En monitor som upptäcker ett problem men inte når fram med larmet är i praktiken lika illa som ingen monitor alls. De flesta lösningar stödjer flera larmkanaler parallellt — e-post, SMS, Slack, Discord, webhooks — så att ett larm når fram även om en kanal av någon anledning inte gör det. QRE8 Watchdog samlar de här kontrolltyperna, inklusive push-baserad heartbeat-monitoring och IoT/LoRaWAN-övervakning, i samma dashboard.