Healthchecks zelf hosten in 2026: cron-pings, alerts en databaseback-ups

Healthchecks zelf hosten wordt interessant bij de eerste redeploy, niet bij de eerste docker run. Als cron-jobs een interne URL pingen of email workers niet draaien, kan Docker nog steeds een volledig gezond proces melden. De deployment hieronder is ingericht rond observeerbaar gedrag: stuur start-, success- en failure-pings vanuit een testjob en laat vervolgens bewust een geplande ping weg, zodat je de alert voor de ontbrekende job ontvangt.

De beoogde taak van Healthchecks is duidelijk: dead-man monitoring voor cron-jobs en background tasks. Die omschrijving maakt duidelijk wat publiek moet blijven, wat privé moet blijven en wat een back-up moet kunnen herstellen.

Maak een back-up van de state die Healthchecks niet kan reconstrueren

De standaard Healthchecks-container heeft geen vereiste mount voor applicatiedata. De recovery-set is desondanks duidelijk: de applicatiedatabase en de notificatieconfiguratie. Maak geen lege volume aan om de deployment stateful te laten lijken; bewaar in plaats daarvan de exacte image-referentie en de gecontroleerde configuratie.

Bouw Healthchecks opnieuw op een lege host en voer de acceptatietransactie uit. Recovery is geslaagd wanneer checks, schedules, integraties en ping keys terugkeren en een bewust ontbrekende ping de verwachte alert activeert. Elke gekoppelde database of collaboration service volgt zijn eigen application-consistent back-upplan, terwijl de vervangbare webcontainer opnieuw uit code wordt opgebouwd. De deployment guide van Git naar productie beschrijft die reproduceerbare grens.

Bewaar een checksum of digest voor de bekende goede image en test opnieuw na updates. Voor een stateless service is een succesvolle rebuild de restore-test; voor externe state moet het Healthchecks-runbook verwijzen naar de afzonderlijke owner en recoveryprocedure.

Bouw een vervangbare Healthchecks-container

Gebruik een commando waarin elke belangrijke keuze zichtbaar is. Deze baseline bindt Healthchecks aan de loopback van de host, voegt de bekende datamounts toe en levert de eerste vereiste instelling aan. Voeg voor production alerts de gecontroleerde connection settings voor Postgres en werkende email delivery toe; gebruik private namen voor 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

Vervang floating tags door een geteste versie of digest. Controleer na het opstarten docker logs --tail 200 healthchecks en bevestig dat het proces op 8000 luistert. Voer daarna de Healthchecks-acceptatieactie uit; een response van de root-pagina bewijst niet dat het volledige scenario slaagt: stuur start-, success- en failure-pings vanuit een testjob en laat vervolgens bewust een geplande ping weg, zodat je de alert voor de ontbrekende job ontvangt.

Waar Healthchecks van afhankelijk is

Trek drie grenzen rond Healthchecks: ingress naar poort 8000, durable state en ondersteunende vereisten. De container is vervangbaar, maar voor de andere twee zijn expliciete owners nodig. Het netwerkcontract voor Healthchecks bestaat uit Postgres en werkende email delivery voor production alerts. Houd private endpoints op interne DNS, sta alleen vereiste uitgaande calls toe en geef Healthchecks een scoped service credential.

Het diagram is compleet wanneer een schone client start-, success- en failure-pings vanuit een testjob kan versturen, waarna een bewust weggelaten geplande ping de alert voor de ontbrekende job activeert. Leg timing- en resourcedata vast voor het aantal checks, grace periods, notification fan-out, email delivery en database writes. Als de transactie mislukt, laat de eerste grens die zich niet gedraagt zoals gedocumenteerd zien of je routing, lokale capaciteit of een ondersteunende service moet onderzoeken.

Routeer Healthchecks zonder HTTPS verkeerd voor te stellen

Kies de definitieve Healthchecks-hostname voordat gebruikers callbacks of client settings opslaan en stel SITE_ROOT en ALLOWED_HOSTS in op het externe HTTPS-adres. De platformroute moet TLS één keer termineren en naar private poort 8000 routeren.

Voer de acceptatietransactie extern uit. Als de client Healthchecks nooit bereikt, gebruik dan de checklist voor SSL-validatie voor DNS- en certificaatcontroles. Als de request Healthchecks wel bereikt, maar cron-jobs een interne URL pingen of email workers niet draaien, stop dan met het aanpassen van proxy redirects en inspecteer in plaats daarvan de applicatiespecifieke grens.

Bewijs dat je moet verzamelen voordat Healthchecks live gaat

Maak een kleine, disposable Healthchecks-fixture en bewaar die voor elke release. De fixture moet de echte workflow testen: stuur start-, success- en failure-pings vanuit een testjob en laat vervolgens bewust een geplande ping weg, zodat je de alert voor de ontbrekende job ontvangt. Leg de image digest, externe hostname, dependency address en het verwachte resultaat vast, zodat een latere operator de test kan herhalen zonder deze guide te hoeven interpreteren.

Voer de fixture drie keer uit. Gebruik eerst de verse deployment. Vervang vervolgens de container zonder durable state aan te raken. Herstel ten slotte de back-up in een lege omgeving. De derde run slaagt alleen wanneer checks, schedules, integraties en ping keys terugkeren en een bewust ontbrekende ping de verwachte alert activeert. Leg tijdens elke run latency en resourcegebruik vast rond het aantal checks, grace periods, notification fan-out, email delivery en database writes; dit wordt de baseline voor alerts in plaats van een willekeurig CPU-percentage.

Test ten slotte bewust het negatieve pad: ontzeg de testidentity tijdelijk toegang tot Postgres en werkende email delivery voor production alerts. Bevestig dat Healthchecks zichtbaar faalt zonder de state te corrumperen, herstel de juiste toestand en herhaal de geslaagde transactie. Een releaserecord met deze vier uitkomsten levert sterker bewijs dan screenshots van een dashboard of een eenmalige curl-response.

Failure drills voor Healthchecks

Observeer het werk dat Healthchecks uitvoert: het aantal checks, grace periods, notification fan-out, email delivery en database writes. Stel limieten in met voldoende headroom voor dat werk en vermijd een liveness probe die ermee concurreert. De operator check moet nog steeds volgens een schema proberen om start-, success- en failure-pings vanuit een testjob te versturen en daarna een geplande ping weg te laten, zodat de alert voor de ontbrekende job wordt ontvangen.

Houd er bij updates rekening mee dat application migrations en workerconfiguratie samen moeten worden geüpgraded, zodat de webpagina een defecte alert delivery niet verbergt. Deploy de candidate tegen een herstelde kopie en herhaal de bekende test. Als cron-jobs een interne URL pingen of email workers niet draaien, gebruik dan runtime logs en de daadwerkelijke network request om te achterhalen welke aanname is veranderd.

Kies de trust boundary van Healthchecks

Sluit het bootstrapvenster zodra de eerste vertrouwde administrator bestaat. De concrete valkuil bij Healthchecks is het gebruik van een gegenereerde secret die bij elke restart verandert; de veiligere grens is een stabiele SECRET_KEY gebruiken, projectlidmaatschap te beperken en ping-URL's als credentials te behandelen.

Genereer SECRET_KEY één keer, houd deze buiten Git en bewaar hem bij het recovery manifest, omdat een wijziging encrypted of signed application state ongeldig kan maken. Private networking moet dependency credentials transporteren en rollen binnen Healthchecks moeten de kleinst bruikbare actie toestaan. Houd gevoelige request bodies en provider responses uit routinematige logs.

Ook een Dockup-deployment heeft een Healthchecks-acceptatietest nodig

Dockup kan de vervangbare platformonderdelen beheren: verkeer naar poort 8000 routeren, het domein en certificaat uitgeven, secrets injecteren, persistente opslag koppelen en Healthchecks verbinden met managed of privaat gekoppelde services. Dit kan op Dockup-infrastructuur of op een server die je koppelt.

De acceptatiewerkzaamheden voor Healthchecks blijven expliciet. Stel na de one-click deployment SITE_ROOT en ALLOWED_HOSTS in op het externe HTTPS-adres, verbind met Postgres en werkende email delivery voor production alerts, test deze verbindingen en voer dit scenario uit: stuur start-, success- en failure-pings vanuit een testjob en laat daarna bewust een geplande ping weg, zodat je de alert voor de ontbrekende job ontvangt. Die verdeling is bewust: Dockup neemt repetitieve infrastructuurconfiguratie weg zonder te doen alsof applicatierollen, provider credentials of restorebeleid zichzelf kiezen.

Veelgestelde vragen

Wat heeft Healthchecks nodig voor een production deployment?

Routeer de Healthchecks-container via één HTTPS-origin op poort 8000. De vereiste ondersteunende network services zijn Postgres en werkende email delivery voor production alerts. Verklaar Healthchecks pas gereed wanneer je start-, success- en failure-pings vanuit een testjob kunt versturen en daarna een geplande ping kunt weglaten, zodat je de alert voor de ontbrekende job ontvangt.

Welke Healthchecks-data hoort in een back-up?

De standaard Healthchecks-image heeft geen vereiste mount voor applicatiedata. Bewaar de deploymentconfiguratie en maak afzonderlijk een back-up van gekoppelde state; recovery is geslaagd wanneer checks, schedules, integraties en ping keys terugkeren en een bewust ontbrekende ping de verwachte alert activeert.

Heeft Healthchecks HTTPS nodig achter een reverse proxy?

Gebruik HTTPS voor de publieke Healthchecks-origin en houd poort 8000 op de interne route. Pas de Healthchecks-instelling correct toe: stel SITE_ROOT en ALLOWED_HOSTS in op het externe HTTPS-adres. Voor Healthchecks beschermt HTTPS credentials of user content tijdens transport en zorgt het voor consistent gedrag van clients die gevoelig zijn voor de origin.

Hoe test je een Healthchecks-upgrade?

Herstel de huidige Healthchecks-state in een geïsoleerde deployment, pas de candidate version toe en herhaal de acceptatietransactie. Let hier vooral op, omdat application migrations en workerconfiguratie samen moeten worden geüpgraded, zodat de webpagina een defecte alert delivery niet verbergt. Bewaar de vorige Healthchecks-image totdat de grenzen voor datamigratie en rollback duidelijk zijn.