Sådan self-hoster du Healthchecks i 2026: Cron-pings, alerts og databasebackups

Det bliver interessant at self-hoste Healthchecks ved den første redeploy – ikke ved den første docker run. Hvis cron-jobs pinger en intern URL, eller email-workers ikke kører, kan Docker stadig rapportere en helt sund proces. Deploymentet nedenfor er bygget op omkring observerbar adfærd: Send start-, success- og failure-pings fra et testjob, udelad derefter en planlagt ping, og modtag alerten om det manglende job.

Healthchecks' formål er entydigt: dead-man-monitorering af cron-jobs og background tasks. Den beskrivelse fortæller os, hvad der skal være offentligt, hvad der bør forblive privat, og hvad en backup skal kunne genskabe.

Tag backup af den state, Healthchecks ikke kan genskabe

Standardcontaineren til Healthchecks har ikke noget påkrævet mount til application data. Recovery-sættet er stadig tydeligt defineret: application-databasen og notification-konfigurationen. Opret ikke et tomt volume bare for at få deploymentet til at se stateful ud; bevar i stedet den præcise image-reference og den gennemgåede konfiguration.

Genopbyg Healthchecks på en tom host, og kør acceptance-transaktionen. Recovery er gennemført, når checks, schedules, integrations og ping keys er tilbage, og en bevidst manglende ping udløser den forventede alert. Alle tilknyttede databaser eller collaboration services følger deres egen application-consistent backup-plan, mens den udskiftelige webcontainer genskabes fra kode. Deployment-guiden fra Git til production beskriver denne reproducerbare grænse.

Gem en checksum eller digest for det kendte, velfungerende image, og test igen efter opdateringer. For en stateless service er en vellykket genopbygning restore-testen; for ekstern state skal Healthchecks-runbooken linke til den separate ejer og recovery-procedure.

Byg en udskiftelig Healthchecks-container

Brug en kommando, der eksponerer alle vigtige valg. Denne baseline binder Healthchecks til hostens loopback, tilføjer de kendte data-mounts og angiver den første påkrævede indstilling. Tilføj de gennemgåede forbindelsesindstillinger til Postgres samt fungerende email-levering til production-alerts, og brug private navne til private services.

docker run -d \
  --name healthchecks \
  --restart unless-stopped \
  -p 127.0.0.1:8000:8000 \
  -e SECRET_KEY=replace-with-a-long-random-value \
  -e SITE_ROOT=https://app.example.com \
  -e ALLOWED_HOSTS=app.example.com \
  -e DB=postgres \
  -e DB_HOST=postgres.internal \
  -e DB_NAME=healthchecks \
  -e DB_USER=healthchecks \
  -e DB_PASSWORD=replace-with-a-strong-database-password \
  healthchecks/healthchecks:latest

Erstat floating tags med en testet version eller digest. Efter opstart skal du inspicere docker logs --tail 200 healthchecks og bekræfte, at processen lytter på port 8000. Udfør derefter Healthchecks' acceptance-test; et svar fra root-siden kan ikke bevise, at hele scenariet fungerer: Send start-, success- og failure-pings fra et testjob, udelad derefter en planlagt ping, og modtag alerten om det manglende job.

Hvad Healthchecks afhænger af

Tegn tre grænser omkring Healthchecks: ingress til port 8000, persistent state og understøttende krav. Containeren kan udskiftes, men de to andre områder kræver tydelige ejere. Netværkskontrakten for Healthchecks er Postgres og fungerende email-levering til production-alerts. Hold private endpoints på intern DNS, tillad kun nødvendige outbound-kald, og giv Healthchecks en afgrænset service credential.

Diagrammet er komplet, når en ren klient kan sende start-, success- og failure-pings fra et testjob, derefter udelade en planlagt ping og modtage alerten om det manglende job. Indsaml timing- og resourcedata for antal checks, grace periods, notification fan-out, email-levering og database writes. Hvis transaktionen fejler, identificerer den første grænse, der ikke opfører sig som dokumenteret, om du skal undersøge routing, lokal kapacitet eller en understøttende service.

Rout Healthchecks uden at give et forkert billede af HTTPS

Vælg det endelige Healthchecks-hostname, før brugerne gemmer callbacks eller client settings, og sæt derefter SITE_ROOT og ALLOWED_HOSTS til den eksterne HTTPS-adresse. Platform-routen skal terminere TLS én gang og pege på den private port 8000.

Kør acceptance-transaktionen eksternt. Hvis klienten aldrig når frem til Healthchecks, kan du bruge checklisten til SSL-validering til DNS- og certifikatkontrol. Hvis requesten når frem til Healthchecks, men cron-jobs pinger en intern URL, eller email-workers ikke kører, skal du stoppe med at ændre proxy-redirects og i stedet undersøge den applikationsspecifikke grænse.

Dokumentation, du skal indsamle, før Healthchecks går live

Opret en lille, disposable Healthchecks-fixture, og behold den til hver release. Fixturen skal afprøve det reelle workflow: Send start-, success- og failure-pings fra et testjob, udelad derefter en planlagt ping, og modtag alerten om det manglende job. Notér image digest, eksternt hostname, dependency-adresse og det forventede resultat, så en senere operator kan gentage testen uden at skulle fortolke denne guide.

Kør fixturen tre gange. Brug først det friske deployment. Udskift derefter containeren uden at ændre persistent state. Til sidst gendanner du backupen i et tomt miljø. Den tredje kørsel er kun godkendt, når checks, schedules, integrations og ping keys er tilbage, og en bevidst manglende ping udløser den forventede alert. Indsaml under hver kørsel latency og ressourceforbrug for antal checks, grace periods, notification fan-out, email-levering og database writes; det bliver baseline for alerts i stedet for en tilfældig CPU-procent.

Test til sidst den negative vej bevidst: Afvis midlertidigt testidentitetens adgang til Postgres og fungerende email-levering til production-alerts. Bekræft, at Healthchecks fejler synligt uden at korrumpere state, genskab den korrekte tilstand, og gentag den vellykkede transaktion. En release-record med disse fire resultater er stærkere evidens end screenshots af et dashboard eller et enkelt curl-svar.

Failure drills for Healthchecks

Observer det arbejde, Healthchecks udfører: antal checks, grace periods, notification fan-out, email-levering og database writes. Sæt limits med headroom til dette arbejde, og undgå en liveness-probe, der konkurrerer med det. Operator-checket skal stadig forsøge at sende start-, success- og failure-pings fra et testjob, derefter udelade en planlagt ping og modtage alerten om det manglende job efter en schedule.

Ved opdateringer skal du huske, at application migrations og worker-konfiguration skal opgraderes samlet, så websiden ikke skjuler fejl i alert-leveringen. Deploy kandidaten mod en genskabt kopi, og gentag den kendte test. Hvis cron-jobs pinger en intern URL, eller email-workers ikke kører, skal du bruge runtime-logs og det faktiske network request til at finde den ændrede antagelse.

Vælg Healthchecks' trust boundary

Luk bootstrap-vinduet, så snart den første betroede administrator findes. Healthchecks' konkrete faldgrube er at bruge en genereret secret, der ændres ved hver restart; den sikrere grænse er at bruge en stabil SECRET_KEY, begrænse project membership og behandle ping URLs som credentials.

Generér SECRET_KEY én gang, hold den ude af Git, og bevar den sammen med recovery-manifestet, fordi en ændring kan gøre krypteret eller signeret application state ugyldig. Private netværk bør transportere dependency credentials, og rollerne i Healthchecks bør kun give den mindst mulige nyttige adgang. Sørg for, at følsomme request bodies og provider-responses ikke kommer i de almindelige logs.

Et Dockup-deployment kræver stadig en Healthchecks-acceptancetest

Dockup kan eje de udskiftelige platformdele: route traffic til port 8000, udstede domain og certificate, injecte secrets, tilknytte persistent storage og forbinde Healthchecks med managed eller privat tilknyttede services. Det kan ske på Dockup-infrastruktur eller på en server, du selv tilknytter.

Acceptance-arbejdet for Healthchecks er stadig eksplicit. Efter one-click-deploymentet skal du sætte SITE_ROOT og ALLOWED_HOSTS til den eksterne HTTPS-adresse, forbinde og teste Postgres samt fungerende email-levering til production-alerts og køre dette scenarie: Send start-, success- og failure-pings fra et testjob, udelad derefter en planlagt ping, og modtag alerten om det manglende job. Denne opdeling er tilsigtet: Dockup fjerner gentagen infrastruktur-opsætning uden at lade som om application roles, provider credentials eller restore policy vælger sig selv.

Ofte stillede spørgsmål

Hvad skal Healthchecks bruge i et production-deployment?

Route Healthchecks-containeren på port 8000 gennem én HTTPS-origin. Det understøttende netværkskrav er Postgres og fungerende email-levering til production-alerts. Kald ikke Healthchecks klar, før du kan sende start-, success- og failure-pings fra et testjob, derefter udelade en planlagt ping og modtage alerten om det manglende job.

Hvilke Healthchecks-data hører hjemme i en backup?

Standardimaget til Healthchecks har ikke noget påkrævet mount til application data. Bevar deployment-konfigurationen, og tag separat backup af al tilknyttet state; recovery er gennemført, når checks, schedules, integrations og ping keys er tilbage, og en bevidst manglende ping udløser den forventede alert.

Kræver Healthchecks HTTPS bag en reverse proxy?

Brug HTTPS til den offentlige Healthchecks-origin, og behold port 8000 på den interne route. Anvend Healthchecks-indstillingen korrekt: Sæt SITE_ROOT og ALLOWED_HOSTS til den eksterne HTTPS-adresse. For Healthchecks beskytter HTTPS credentials eller brugerindhold under transport og sikrer ensartet origin-følsom client-adfærd.

Hvordan skal en Healthchecks-opgradering testes?

Gendan den aktuelle Healthchecks-state i et isoleret deployment, anvend kandidatversionen, og gentag acceptance-transaktionen. Vær særligt opmærksom, fordi application migrations og worker-konfiguration skal opgraderes samlet, så websiden ikke skjuler fejl i alert-leveringen. Behold det tidligere Healthchecks-image, indtil dets data-migration- og rollback-grænse er forstået.