Pingdom och UptimeRobot kontrollerar dina webbplatser utifrån och säger till när en slutar svara. Atlassian Statuspage är sidan där du berättar det för dina kunder. Uptime Kuma och Gatus gör båda jobben på en egen server, till ett fast serverpris i stället för ett pris per kontroll. Vi lät båda bevaka samma testtjänster på samma server, och sedan förstörde vi tjänsterna med flit. Vad de tre tjänsterna kostar, och vad du ger upp när du lämnar dem, står i slutet.
Det korta svaret
Välj Uptime Kuma om du vill klicka ihop dina bevakningar i ett webbgränssnitt, gärna på svenska, och vill ha en statussida där du kan prata med dina kunder: den har incidentinlägg med historik, underhåll som syns på sidan, och den larmade inom 9 till 50 sekunder i vårt test med sina standardinställningar. Räkna med att den har ett enda konto utan roller, att den använde ungefär tio gånger så mycket minne som Gatus och att den saknar ett API som stöds för att lägga till bevakningar från ett skript.
Välj Gatus om du hellre har dina bevakningar i en enda textfil under versionshantering, vill ha strikta villkor på svarstid, innehåll och certifikat, och vill ha något pyttelitet: den använde 12 till 17 MB minne med 50 bevakningar. Räkna med att hela översikten är statussidan, att meddelanden till besökarna är rader i samma fil, att den saknar svenska, och att den med sina standardinställningar väntar på tre misslyckade kontroller och därför larmade först efter två till nästan tre minuter.
Vilken du än väljer: kör den någon annanstans än det den bevakar, och låt något utanför kontrollera kontrollanten. En bevakning i samma datacenter som dina webbplatser tystnar precis när du behöver den som mest.
Det här testade vi
Vi installerade båda på samma nya Melonslab VC-P Alloy (2 vCPU, 8 GB) med Debian 13. Uptime Kuma 2.5.6 kom från vår guide Uptime Kuma med rootless Podman, steg för steg, och varje steg fungerade som det stod skrivet. Gatus 5.37.0 har ingen guide hos oss, så vi körde den på samma sätt, utan root under en egen användare, som en Quadlet-enhet bakom samma Caddy, med konfigurationen i en fil och datan i SQLite. Avsnittet Så körde vi Gatus längre ner har enhetsfilen och konfigurationen.
På samma server körde vi testtjänster som vi kunde förstöra när vi ville:
- en liten webbplats som svarade "All systems go", som vi stoppade och ändrade så att den sa något annat;
- en sida som alltid svarade med fel 500, och en som tog 15 sekunder på sig att svara;
- en TLS-tjänst med ett certifikat som gick ut två dagar senare, signerat av en egen testutfärdare som vi lät båda apparna lita på;
- en TCP-port, som vi stoppade samtidigt som webbplatsen;
- en DNS-uppslagning av vår testdomän via Quad9, och en ping till Quad9;
- ett hjärtslag (heartbeat), ett jobb som rapporterade in varje minut, som vi stoppade.
Båda kontrollerade allt var 60:e sekund, vilket är deras standard, med en rapport från hjärtslaget varannan minut, och skickade larm via e-post, till en webhook och till ntfy. E-posten gick till Mailpit, en testbrevlåda på servern, så inga riktiga mejl skickades, och webhooken gick till en liten mottagare som skrev upp tiden för varje anrop. Sedan stoppade vi webbplatsen och TCP-porten fyra gånger i fem minuter, på slumpvisa ställen i kontrollcykeln, och tog tid på varje larm från det ögonblick vi stoppade dem. Vi provade också ett underhållsfönster, byggde en publik statussida på en egen domän med incidenter och badges, lade till 41 bevakningar till så att vi hade 50 i varje och lät dem gå i tre timmar, startade om servern, och säkerhetskopierade och återställde Gatus.
Pingdom, UptimeRobot och Statuspage testade vi inte. Vi skapade inga konton hos dem. Det sidan säger om dem kommer från deras egna prissidor och dokumentation, som vi länkar till där vi använder dem och läste den 14 oktober 2026.
Siffrorna
| Uptime Kuma 2.5.6 | Gatus 5.37.0 | |
|---|---|---|
| Containrar | 1 | 1 |
| Avbild på disken | 1,76 GB | 51 MB |
Från useradd till första sidan | 70 sekunder | 15 sekunder |
| Minne i vila efter omstart, 9 bevakningar | 118 MB | 12 MB |
| Minne med 50 bevakningar | 120 till 141 MB | 12 till 17 MB |
| CPU med 50 bevakningar, var 60:e sekund | 2,5 % av en kärna | 0,5 % av en kärna |
| Datatillväxt med 50 bevakningar | 0,5 MB i timmen, omkring 12 MB per dygn | 2,3 MB första timmen, sedan 0,2 MB i timmen |
| Larm efter att en webbplats stoppats, standardinställningar | 9 till 50 sekunder | 2 minuter 2 sekunder till 2 minuter 44 sekunder |
| Klartecken när den var tillbaka | 9 till 50 sekunder | 62 till 104 sekunder |
| Falsklarm i vårt test | inga | inga |
| Bevakningar ställs in i | webbgränssnittet | en YAML-fil |
| Publik statussida | separata sidor där du väljer bevakningar, med incidenter | själva översikten, med meddelanden |
| Användare | ett konto | inga konton; ett lösenord eller enkel inloggning (SSO) för hela sajten om du vill |
| Svenskt gränssnitt | ja | nej |
| Licens | MIT | Apache 2.0 |
Minnet är vad podman stats visade för varje container, i vila fem minuter efter en omstart och som spannet under tre timmar med 50 bevakningar. CPU är den genomsnittliga andelen av en kärna under de tre timmarna, från containrarnas egna räknare. Installationstiderna är hur lång tid kommandona tog att köra, nedladdningen av avbilden inräknad, tills första sidan svarade. Båda avbilderna var den senaste versionen den 14 oktober 2026.
En bevakning kan inte larma om sitt eget avbrott
Det här är den viktigaste punkten på sidan, och den gäller båda apparna.
I vårt test körde båda apparna på samma server som tjänsterna de bevakade, eftersom det var enda sättet att förstöra tjänsterna med flit. I verkligheten är det just den uppsättningen du ska undvika. Om servern stannar, eller om datacentret förlorar ström eller nät, stannar bevakningen med den. Den skickar inget larm, eftersom den inte är igång, och dess statussida försvinner också, precis när dina kunder letar efter den. Även på en annan server i samma datacenter slår ett nätverksfel där ut båda på en gång.
Lösningen är billig, och du kan göra det ena eller båda:
- Kör bevakningen på en andra, separat server, helst hos en annan leverantör eller åtminstone i ett annat datacenter, och låt den kontrollera dina webbplatser över internet. En liten server räcker: Gatus använde som mest 17 MB och Uptime Kuma 141 MB med 50 bevakningar.
- Låt något utanför bevaka bevakningen. En gratis extern kontroll, som UptimeRobots gratisnivå eller en andra bevakning på en annan server, kan hämta din statussida med några minuters mellanrum och säga till när den slutar svara. Gatus har adressen
/healthför det, och för Uptime Kuma kontrollerar du själva statussidan. Två egna bevakningar på två servrar kan också bevaka varandra. Vi provade det med våra två: när vi stoppade Uptime Kuma svarade dess statussida med fel 502 och Gatus larmade 2 minuter 17 sekunder senare, och när vi stoppade Gatus larmade Uptime Kuma 6 sekunder senare.
Ingen av dem gör din bevakning till Pingdom. En extra server är ett ställe till att kontrollera från, inte dussintals, vilket avsnittet om vad du ger upp förklarar. Men det är skillnaden mellan att få veta det av en bevakning och att få veta det av en kund.
Installation
Uptime Kuma är en container och ett block i Caddy. Vid första besöket frågar den vilken databas den ska använda, där SQLite är det enkla valet, och efter ett konto, och sedan lägger du till bevakningar i ett formulär. Vår guide ger också containern en egen adress så att den når appar bakom Caddy på samma server. Avbilden är stor, 1,76 GB, eftersom den innehåller Node.js, Chromium för sina webbläsarkontroller och en inbyggd MariaDB, och den nedladdningen var det mesta av de 70 sekunderna.
Gatus är en container, ett block i Caddy och en YAML-fil. Den har ingen installationssida och inga konton: den börjar bevaka det som står i filen, och sidan visar resultaten. Avbilden är 51 MB, ett enda program. Vi valde SQLite framför PostgreSQL för lagringen: det är en fil i en volym, säkerhetskopian är ett kommando, och Gatus sparar bara de senaste 100 resultaten per bevakning, så filen förblir liten. PostgreSQL skulle lägga till en container och mer minne utan någon vinst i den här storleken. Utan någon av dem håller Gatus allt i minnet och glömmer det vid varje omstart.
Vi använde samma ändring i containers.conf som i vår Uptime Kuma-guide även för Gatus, så att den också nådde tjänster bakom Caddy på samma server.
Kontroller och larm
Båda kontrollerar webbplatser, nyckelord på sidan, TCP-portar, DNS-svar, ping, certifikat och hjärtslag. Uptime Kuma har fler sorter, ett 40-tal, bland annat databaser, spelservrar, Docker-containrar och en riktig webbläsare. Gatus har färre, men varje kontroll är en lista med villkor som du kombinerar: statuskoden, svarstiden, innehållet som text eller JSON, IP-adressen och dagarna kvar på certifikatet.
Hur snabbt de larmade. Skillnaden kom från standardinställningarna, inte från snabbheten. Uptime Kuma larmar vid första misslyckade kontrollen: när vi stoppade webbplatsen kom larmet 9, 14, 16 och 50 sekunder senare i våra fyra omgångar, beroende på var i dess 60-sekunderscykel vi stoppade den. Gatus väntar på tre misslyckade kontroller i rad, och på två lyckade innan klartecknet: dess larm kom efter 2 minuter 2 sekunder till 2 minuter 44 sekunder, och klartecknet efter 62 till 104 sekunder. TCP-porten betedde sig likadant i båda. Varje avbrott gav exakt ett larm och ett klartecken i varje kanal, och mejlet, webhooken och ntfy-meddelandet kom inom en sekund från varandra. Allt detta går att ställa in: Uptime Kuma har Retries, och Gatus har failure-threshold och success-threshold på varje larm.
Falsklarm. Ingen av dem skickade ett enda larm som vi inte själva hade orsakat, under omkring fem timmar med 9 till 50 bevakningar. Det enda larmet utanför våra tester kom från Uptime Kuma under vår omstart: den såg den långsamma sidan gå ner när servern stängdes av, vilket stämde. Våra tjänster låg dock på samma server, så det här säger inget om ett ostadigt nät mellan en bevakning och en webbplats långt bort, och det är där Gatus tre misslyckanden i rad är värda sin fördröjning.
Vad som räknades som nere skilde sig:
- Den långsamma sidan, 15 sekunder, var uppe i Uptime Kuma, vars tidsgräns är 48 sekunder vid en kontroll var 60:e sekund, och nere i Gatus efter dess tidsgräns på 10 sekunder. Båda tidsgränserna går att ändra, och Gatus kan också fälla en kontroll på
[RESPONSE_TIME] < 2000. - Certifikatet med två dagar kvar: Uptime Kuma lät bevakningen vara uppe och skickade en separat varning, "server certificate tls.example.com will expire in 1 days", när vi hade kryssat i Certificate Expiry Notification, som är avslagen för nya bevakningar. Den varnar 21, 14 och 7 dagar innan som standard. I Gatus gjorde villkoret
[CERTIFICATE_EXPIRATION] > 168hbevakningen röd och larmade som vid alla andra fel. - När vi ändrade nyckelordet på sidan larmade Uptime Kuma 54 sekunder senare och Gatus efter 2 minuter 47 sekunder.
- Hjärtslaget: när vårt jobb slutade rapportera larmade Uptime Kuma två minuter efter den sista rapporten, som inställt. Gatus noterade den första uteblivna rapporten 3 minuter 42 sekunder efter den sista, men hade inte larmat när vi startade jobbet igen efter sex och en halv minut: den kontrollerar ett hjärtslag en gång per intervall, här två minuter, och ville ändå ha tre misslyckanden, vilket hade tagit nästan åtta minuter. Med
failure-threshold: 1på det larmet larmade nästa försök 2 minuter 10 sekunder efter den sista rapporten. Ställ in det för varje hjärtslag i Gatus.
Larmkanaler. Uptime Kuma har omkring 100 sorters aviseringar, som du ställer in i formulär: e-post, webhooks, ntfy, Matrix, Slack, Teams, Telegram, Pushover, SMS-tjänster och många fler. Gatus har ett 40-tal, inställda i filen, bland annat e-post, en egen webhook, ntfy, Matrix, Slack, Teams, Telegram, PagerDuty och Twilio. Två saker märkte vi med e-posten i Gatus: den vägrade skicka sitt lösenord över en okrypterad förbindelse, vilket är rätt, så använd port 587 med STARTTLS, som i vårt test; och när ett utskick misslyckades försökte den igen vid nästa kontroll i stället för att ge upp.
Underhållsfönster
Båda höll tyst när vi stoppade webbplatsen under ett planerat fönster.
- Uptime Kuma har Maintenance i menyn: ett fönster en gång, ett återkommande, ett cron-uttryck eller ett manuellt som du avslutar själv, för de bevakningar och statussidor du väljer. Under vårt visade bevakningen och dess badge Maintenance i blått i stället för nere, och statussidan visade det också.
- Gatus har en lista
maintenance-windowsper bevakning, eller ett fönster för alla, med starttid, längd, tidszon och veckodagar, i filen. Den skickade inga larm, men sidan fortsatte att visa de misslyckade kontrollerna i rött, utan något tecken på underhåll. Berätta det för dina besökare med ett meddelande.
Ingen av dem kan starta ett fönster från din kalender eller ett API-anrop utan ett skript.
Statussida
Uptime Kuma håller isär bevakningen och den publika sidan. Du gör en eller flera statussidor, väljer vilka bevakningar varje sida visar och under vilka rubriker, och ger var och en en egen domän: vi skrev in status.example.com under Domain Names i sidans inställningar, lade till ett Caddy-block för den som pekade på Uptime Kuma, och statussidan öppnades på domänens startsida, medan administrationen låg kvar på sin egen adress. Du skriver incidenter på sidan med en rubrik, text i Markdown och en färg. I 2.5.6 kan en incident markeras som löst, och lösta flyttar ner till Past Incidents, så att kunderna ser en historik. Varje bevakning visar sina senaste kontroller och sin drifttid i procent. Badges för status, drifttid, svarstid och certifikatets utgång kommer från /api/badge/, för bevakningar som finns på en publik statussida.
Gatus har ingen separat sida: översikten är statussidan, och den visar varje bevakning i filen, med de senaste kontrollerna och svarstiderna. Du kan dölja en bevaknings adress med hide-hostname och hide-url, men du kan inte visa en uppsättning bevakningar för kunderna och en annan för dig själv i samma Gatus, så kör två om du behöver det. Incidenter är announcements i filen, var och en med en tid, en typ (outage, warning, information, operational) och ett meddelande i Markdown. Arkiverade flyttade ner till Past Announcements längst ner, under en lista med dagar. En egen domän är bara blocket i Caddy. Badges för hälsa, drifttid och svarstid kommer från /api/v1/endpoints/…/badge.svg.
Historiken skiljer sig också. Uptime Kuma sparar varje kontroll i 365 dagar som standard och ritar diagram av dem. Gatus sparar de senaste 100 resultaten och 50 händelserna per bevakning och drifttiden i 30 dagar, vilket räcker för en statussida men inte för en rapport ett år senare.
Ingen av dem skickar mejl till prenumeranter när du skriver en incident, som Statuspage gör. Uptime Kumas statussidor har ett RSS-flöde; Gatus har inget.
Användare och behörigheter
Uptime Kuma har ett konto. Alla som sköter bevakningarna delar det, med tvåstegsinloggning om du slår på den, och det finns inga roller, inga användare som bara får läsa och ingen logg över vem som ändrade vad. Dess API-nycklar öppnar bara dess mätvärden för Prometheus.
Gatus har inga konton alls. Filen är konfigurationen, så den som får ändra bevakningarna är den som får ändra filen, eller Git-förrådet den kommer från, som också ger dig historik över varje ändring. Själva sidan är publik, eller så skyddar du hela den med ett användarnamn och lösenord, eller med enkel inloggning via OpenID Connect, vilket också döljer den för dina kunder.
Behöver flera personer egna inloggningar med olika rättigheter klarar ingen av dem det, och det är ett av de tydligaste skälen att stanna kvar hos en tjänst.
Konfiguration som kod
Gatus är byggd för det. Alla våra 50 bevakningar, deras larm, meddelanden och underhållsfönster var en enda YAML-fil, och Gatus märkte själv när filen ändrades och läste in den igen, inom ungefär en minut i vårt test. Ett fel i filen är faran: när vi förstörde den med flit stannade Gatus, misslyckades vid varje omstart, och statussidan och alla larm var borta tills vi rättade filen. Kör podman logs gatus efter varje ändring. Inställningen skip-invalid-config-update: true låter i stället den gamla konfigurationen fortsätta, vilket Gatus README avråder från, eftersom nästa omstart då misslyckas ändå. Värden som lösenord kan komma från miljövariabler, som vi fyllde från podman secret.
Uptime Kuma ställer du in genom att klicka. Den har inget API för bevakningar som stöds: vi lade till våra 50 via den socketförbindelse som dess eget webbgränssnitt använder, med ett litet skript, vilket fungerar men kan ändras i vilken version som helst. Dess säkerhetskopiering och import som JSON togs bort i version 2. För en handfull bevakningar som någon klickar ihop en gång går det bra; för hundratals, eller ett team som granskar ändringar, gör det inte det.
Svenska
Uptime Kuma finns på svenska: den följde vår webbläsares språk och visade "Användarnamn", "Lösenord" och "Logga in", och du byter under Settings > Appearance > Language, på svenska Inställningar > Utseende > Språk. Bara ett 50-tal av dess 1 600 texter var kvar på engelska, mest ord som "Ping", "URL" och "Token". Den publika statussidan följer varje besökares webbläsare på samma sätt: vår sa "Alla system i drift", medan incidenterna, rubrikerna och bevakningarnas namn stod som vi skrev dem.
Gatus finns bara på engelska. Texterna du skriver själv, rubriken, bevakningarnas namn och meddelandena, kan vara på svenska, men etiketter som "Healthy", "Unhealthy" och "Past Announcements" förblir engelska.
Resurser
Vi lade till 41 bevakningar i varje, 33 webbsidor, 3 kontroller av nyckelord, 2 TCP-portar, 2 DNS-uppslagningar och en ping, totalt 50, och lät båda gå i tre timmar med en kontroll var 60:e sekund.
Minne. Uptime Kuma använde 120 till 141 MB, i snitt 134 MB, lite mer än de 118 MB den använde med nio bevakningar. Gatus använde 12 till 17 MB, i snitt 16 MB.
CPU. Uptime Kuma använde i snitt 2,5 % av en kärna och Gatus 0,5 %. Ingen av dem skulle märkas på en server med två kärnor.
Disk. Båda skriver till SQLite. Uptime Kumas data växte jämnt, med omkring 0,5 MB i timmen, eller 12 MB per dygn. Den sparar varje kontroll i 365 dagar, så i den takten skulle den nå omkring 4,5 GB efter ett år med 50 bevakningar; Settings > Monitor History (Inställningar > Övervakarhistorik) kortar det. Gatus växte med 2,3 MB första timmen, medan den fyllde på upp till sina 100 resultat per bevakning, och sedan med 0,2 MB i timmen, mest drifttidssiffrorna som den sparar i 30 dagar. Efter testet rymde varje datavolym omkring 6 MB, det mesta SQLites skrivlogg (write-ahead log).
Båda får gott och väl plats på den minsta server du skulle köra en bevakning på. Som en andra bevakningsserver får Gatus också plats bredvid annat på en server som redan har fullt upp.
Uppdateringar och säkerhetskopior
Uptime Kuma-guiden följer taggen 2-rootless, som får varje version av version 2 via Podmans dagliga automatiska uppdatering. Gatus följer taggen stable på samma sätt, som var samma avbild som 5.37.0 när vi testade. Uptime Kuma släppte sex versioner mellan 22 augusti och 9 oktober 2026; Gatus släpper en ny version med en till fyra månaders mellanrum, senast den 24 september 2026.
Uptime Kumas säkerhetskopia är en volym, med containern stoppad en kort stund: bevakningar, historik, kontot och aviseringsinställningarna med sina lösenord. Vår var 2,2 MB efter fem timmar med upp till 51 bevakningar. Gatus säkerhetskopia är volymen med SQLite-filen och YAML-filen; spara också lösenorden i podman-hemligheterna på ett säkert ställe, eftersom ingen av dem innehåller dem. Vi exporterade Gatus volym, 1,7 MB efter en timme, tog bort den, importerade den igen, och hela historiken fanns kvar. Båda kom tillbaka av sig själva efter en omstart.
Licens och kostnad
Vi kontrollerade projektens egna sidor den 14 oktober 2026.
- Uptime Kuma är öppen källkod under MIT-licensen, gjord av Louis Lam och dess community. Det finns ingen betalversion och ingen tjänst i molnet från projektet.
- Gatus är öppen källkod under Apache 2.0-licensen, gjord av TwiN. Dess README hänvisar till Gatus.io, en version i molnet, som listade nivåer från Free, utan publicerad sida, via Standard för 10 US-dollar i månaden för en statussida med 30 bevakningar som kontrolleras varannan minut, till Enterprise för 500 US-dollar.
På egna servrar kostar båda inget utöver servrarna. Två små, en för dina webbplatser och en för bevakningen, är den ärliga uppsättningen.
Pingdom, UptimeRobot och Statuspage i dag
Det som följer kommer från deras egna sidor, lästa den 14 oktober 2026, inte från våra tester. Priserna är vad sidorna visade för oss, utan moms.
Pingdom, från SolarWinds, prissätter sin Synthetic Monitoring efter antal kontroller på sin prissida: från 16 euro i månaden, eller 14,33 euro i månaden vid årsbetalning, för 10 drifttidskontroller, en avancerad kontroll och 50 SMS-larm, och 66 euro i månaden, eller 60,50 vid årsbetalning, för 50 drifttidskontroller, 10 avancerade kontroller och 200 SMS. Sidan listar obegränsat antal användare, larm via e-post och SMS, underhållsfönster och publika statussidor. Pingdoms kontroller görs från "probe servers, located around the world", och en misslyckad kontroll räknas som nere bara "if the second test fails" från en annan mätpunkt, "as geographically different as possible", enligt dess dokumentation. Dess publika statussida finns en per organisation, kan ligga på din egen domän, kan inte lösenordsskyddas och visar resultaten av dina kontroller; sidan nämner inga incidentinlägg.
UptimeRobots prissida listar:
- Free: 50 bevakningar som kontrolleras var 5:e minut, enkla statussidor, inga krediter för SMS eller samtal och inga inloggningar för kollegor, "Good for hobby and non-profit projects". Dess villkor säger att "UptimeRobot is available for any use, including commercial and business use", och att gratisnivån "includes 1 status page with a unique UptimeRobot URL only".
- Solo: 10 euro i månaden, 9 vid årsbetalning, för 10 bevakningar, eller 22 euro för 50, som kontrolleras var 60:e sekund, med 3 statussidor på egen domän, underhållsfönster och 10 till 20 krediter för SMS eller samtal.
- Team: 41 euro i månaden, 35 vid årsbetalning, för 100 bevakningar var 30:e sekund, 3 platser för användare, 100 statussidor, webhooks, lösenordsskyddade statussidor, prenumeranter på dem och 30 krediter för SMS eller samtal.
Dess bevakningar kan kontrollera från utvalda platser, listat som "Location-specific monitoring".
Atlassian Statuspage är en statussida, ingen bevakning: Atlassians sida om integrationer säger "Integrate Statuspage with DataDog, New Relic, Librato or Pingdom to update your page as soon as an issue is detected", eller att du uppdaterar den via REST-API:t eller med e-post. Dess prissida listar publika sidor som Free, med 100 prenumeranter, 25 komponenter och 2 teammedlemmar; Hobby för 29 US-dollar i månaden, med 250 prenumeranter, 5 teammedlemmar, egen domän och bara aviseringar via e-post; Startup för 99 US-dollar, med 1 000 prenumeranter, 10 teammedlemmar och aviseringar via SMS och webhook; och Business för 399 US-dollar. Privata sidor, bara för personalen, börjar på 79 US-dollar i månaden.
Det här ger du upp jämfört med Pingdom och Statuspage
En egen bevakning kostar ett fast serverpris, håller dina kontroller och larm på servrar i Sverige och har ingen gräns för antal bevakningar eller hur ofta de körs. Men var ärlig om vad du lämnar:
- Kontroller från många platser. Pingdom kontrollerar från mätpunkter världen över och frågar en andra mätpunkt innan den säger att en webbplats är nere. Din bevakning kontrollerar från ett ställe, så den kan inte skilja en webbplats som är nere från ett nätverksfel mellan de två, eller säga att din webbplats är långsam från Asien. Uptime Kuma 2.5 har bevakningstypen Globalping, som lånar frivilliga mätpunkter världen över, med en gräns på 250 tester i timmen utan konto; den testade vi inte.
- SMS och samtal. I Pingdom och UptimeRobot ingår SMS-krediter, och i UptimeRobot även samtal. Ingen av apparna skickar SMS själv: Uptime Kuma och Gatus skickar via betaltjänster som Twilio, med ett eget konto, eller så använder du ntfy, Pushover eller Telegram på telefonen i stället.
- En statussida som är uppe. Statuspage och de andra tjänsterna kör din statussida på sin infrastruktur, skild från din. Din är bara så tillgänglig som servern den körs på, och därför hör den hemma på en annan server än dina webbplatser.
- Prenumeranter. Statuspage mejlar och sms:ar dina kunder när du skriver en incident. Ingen av apparna har prenumeranter.
- Konton för teamet. Pingdom listar obegränsat antal användare och Statuspage upp till 25 teammedlemmar på Business. Uptime Kuma har ett konto och Gatus inga.
- Driften. Uppdateringar, säkerhetskopior och servern är dina, och om bevakningen stannar märker ingen annan det, om du inte har satt upp kontrollen utifrån.
Så körde vi Gatus
Vi körde Gatus som våra appguider: utan root i Podman under en egen användare, som en Quadlet-enhet bakom Caddy från Podman-guiden, med konfigurationen som en fil och lösenorden som podman-hemligheter. Gatus fyller i ${SMTP_PASSWORD} och ${HEARTBEAT_TOKEN} i sin fil från miljövariabler, och det är där hemligheterna hamnar. Den publicerar på 127.0.0.1:8150.
Som root, skapa användaren:
useradd -m -s /bin/bash gatus
loginctl enable-linger gatus
machinectl shell gatus@
Som gatus, skapa ~/.config/containers/containers.conf precis som i steg 2 i Uptime Kuma-guiden, så att Gatus når appar bakom Caddy på samma server. Sedan hemligheterna, med lösenordet från din e-postleverantör, och en token för hjärtslaget:
printf %s 'the-smtp-password' | podman secret create smtp-password -
openssl rand -hex 24 | tr -d '\n' | podman secret create heartbeat-token -
podman secret inspect --showsecret --format '{{.SecretData}}' heartbeat-token
Det sista kommandot visar token, för jobbet som rapporterar in. Skapa ~/gatus/config.yaml:
storage:
type: sqlite
path: /data/data.db
ui:
title: "Status | Example"
header: "Example"
dashboard-heading: "Status"
dashboard-subheading: "Our services right now"
alerting:
email:
from: "status@example.com"
username: "status@example.com"
password: "${SMTP_PASSWORD}"
host: "smtp.example.com"
port: 587
to: "anna@example.com"
default-alert:
send-on-resolved: true
endpoints:
- name: Website
group: Public
url: "https://www.example.com/"
conditions:
- "[STATUS] == 200"
- "[BODY] == pat(*Welcome*)"
- "[CERTIFICATE_EXPIRATION] > 336h"
alerts:
- type: email
- name: Mail
group: Public
url: "tcp://mail.example.com:993"
conditions:
- "[CONNECTED] == true"
alerts:
- type: email
external-endpoints:
- name: Nightly backup
group: Internal
token: "${HEARTBEAT_TOKEN}"
heartbeat:
interval: 25h
alerts:
- type: email
failure-threshold: 1
Webbplatsen räknas som nere om den inte svarar 200, om ordet "Welcome" saknas på sidan eller om certifikatet går ut inom 14 dagar. failure-threshold: 1 gör att ett uteblivet hjärtslag larmar direkt, se ovan. Lägg till announcements: och maintenance-windows: som de beskrivs i sina avsnitt, och andra larmtyper från Gatus README.
Skapa ~/.config/containers/systemd/gatus.container:
[Unit]
Description=Gatus
[Container]
ContainerName=gatus
Image=ghcr.io/twin/gatus:stable
# The directory, not the file, so that Gatus sees changes
Volume=%h/gatus:/config:ro
Volume=gatus-data:/data
Secret=smtp-password,type=env,target=SMTP_PASSWORD
Secret=heartbeat-token,type=env,target=HEARTBEAT_TOKEN
# Only Caddy, on this server, can reach Gatus
PublishPort=127.0.0.1:8150:8080
# ping needs raw sockets
AddCapability=NET_RAW
AutoUpdate=registry
[Service]
Restart=always
[Install]
WantedBy=default.target
Starta den:
systemctl --user daemon-reload
systemctl --user start gatus
systemctl --user enable --now podman-auto-update.timer
podman logs gatus
Loggen visar Validated 2 endpoints och sedan varje kontroll. Gå tillbaka till root med exit, byt till machinectl shell caddy@, lägg till det här blocket i ~/Caddyfile och starta om Caddy med systemctl --user restart caddy:
status.example.com {
reverse_proxy 127.0.0.1:8150
}
https://status.example.com är nu din statussida. Nattjobbet rapporterar in med:
curl -fsS -X POST -H "Authorization: Bearer THE_TOKEN" \
"https://status.example.com/api/v1/endpoints/internal_nightly-backup/external?success=true"
För att säkerhetskopiera, som gatus:
umask 077
mkdir -p ~/backup
systemctl --user stop gatus
podman volume export gatus-data > ~/backup/gatus-data.tar
cp ~/gatus/config.yaml ~/backup/
systemctl --user start gatus
Spara också SMTP-lösenordet och token på ett säkert ställe: podman-hemligheter ingår inte i säkerhetskopian. För att återställa stoppar du Gatus, kör podman volume rm gatus-data, podman volume create gatus-data och podman volume import gatus-data ~/backup/gatus-data.tar, och startar den igen.
Vilken ska du välja
Ett litet företag som vill ha larm och en statussida för sina kunder: Uptime Kuma. Den ligger närmast UptimeRobot plus en enkel Statuspage: bevakningar i ett formulär, larm vid första felet, incidenter med historik, underhåll som syns på sidan, och svenska. Dess svaga sidor är ett delat konto, en stor avbild och omkring 140 MB minne med 50 bevakningar, inget API som stöds och inga prenumeranter. Följ Uptime Kuma-guiden, på en VC-P Alloy, och helst inte den som dina webbplatser körs på.
Ett team som har sina servrar i Git: Gatus. En YAML-fil håller varje kontroll, larm och meddelande, med villkor på status, innehåll, svarstid och certifikat, i under 20 MB minne. Dess svaga sidor är en översikt som också är den publika sidan, meddelanden som du redigerar i en fil, inga konton, ingen svenska, och standardinställningar som väntar på tre misslyckade kontroller innan de larmar, även vid ett uteblivet hjärtslag. Kör den som i avsnittet Så körde vi Gatus ovan; den får plats på vilken server som helst, även bredvid andra appar.
Stanna hos Pingdom eller UptimeRobot om du behöver kontroller från många länder, SMS eller samtal som ingår, eller flera kollegor med egna inloggningar. Stanna hos Statuspage om du har många kunder som prenumererar på dina incidenter via e-post eller SMS.
Vilken du än kör: lägg den på en andra server och peka en gratis kontroll utifrån mot den.