personal_infra/ansible/roles/forgejo_runner/templates/healthcheck.service.j2

[Unit]
Description=Forgejo Runner Healthcheck
After=network.target

[Service]
Type=oneshot
ExecStart={{ healthcheck_script_path }}
Environment=HEALTHCHECK_PUSH_URL={{ healthcheck_push_url }}
Environment=HEALTHCHECK_PUSH_TOKEN={{ healthcheck_push_token }}
User=root
StandardOutput=journal
StandardError=journal

[Install]
WantedBy=multi-user.target
forgejo-runner: convert to a role, de-Uptime-Kuma the health check 409-line playbook becomes a 16-line playbook plus a 318-line role with phases split across tasks/{prerequisites,install,configure,service,healthcheck}.yml and four templates. forgejo_runner_vars.yml is deleted; its content is the role's defaults. Applies the Plan 6 Stage 0 decision: keep whatever determines whether the service is healthy, drop the Uptime Kuma specifics, make the reporting point pluggable. Gone from the role: the embedded Python that created monitors over the Kuma API, the /tmp credentials file, token extraction, the systemd Environment= rewrite, and 8 `when: uptime_kuma_enabled` guards. What remains is the check itself, its log, the systemd unit and timer, and an honest exit code - `systemctl is-failed forgejo-runner-healthcheck.service` now answers the question with no monitoring system involved at all. Reporting is one variable, healthcheck_push_url, empty by default. Any endpoint that accepts an HTTP ping plugs in there. A pull-based monitor wants it left empty and reads unit state instead. PREMISE CORRECTION: Uptime Kuma is NOT dead. Plan 3 recorded "48 push timers curling an endpoint that no longer answers" and Plan 6 said the check had "nowhere to report to". Both wrong - 24+ push scripts across 11 hosts are pushing successfully right now (HTTP 200). Only the Ansible code and the vault credentials were decommissioned; the service never stopped. So the existing push URLs were harvested into a vaulted healthcheck_push_urls dict and are preserved, keeping this refactor behaviour-neutral. Retiring Kuma stays a deliberate act rather than a side effect. PLAN_3 and PLAN_6 are corrected. Verified: - task-list diff vs the old playbook shows ONLY the five Kuma tasks removed, everything else identical and in the same order - first run ok=22 changed=1 (the rewritten health script); both systemd units and forgejo-runner.service came back ok, so the templates reproduce the previous files byte-for-byte - second run ok=22 changed=0, fully idempotent - still reports "Ping sent successfully (HTTP 200)" from a script containing zero Uptime Kuma references - the 4 skipped tasks are genuine already-configured guards, checked not assumed Two things for the next service: - import_tasks, not include_tasks. Dynamic includes are opaque to --list-tasks, which is the primary verification tool here; the first attempt produced a useless diff. - `Assert runner is running` was guarded by uptime_kuma_enabled and so had not run since the decommissioning. It is not monitoring, it is the deployment checking its own work - the deprecation banner swept it up with the Kuma plumbing, and a runner that failed to start was deploying "successfully" in silence. Ungated now. The banner was applied to contiguous blocks, so read every uptime_kuma_enabled guard and ask whether it is monitoring or deployment. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> 2026-09-12 18:15:29 +02:00			`[Unit]`
			`Description=Forgejo Runner Healthcheck`
			`After=network.target`

			`[Service]`
			`Type=oneshot`
			`ExecStart={{ healthcheck_script_path }}`
uptime kuma: remove every live reference, repoint the probes to Gatus Nothing in the repo pushes to, authenticates against, or is gated by Uptime Kuma any more. ── The sixth instance of the banner bug ──────────────────────────────────── memos had `Restart memos` guarded by `uptime_kuma_enabled`, because the deprecation banner was placed immediately above it and swept it in. It is a HANDLER, so every memos config change since 2026-09-11 applied to disk and silently never restarted the service. Ungated. That is the same failure found in forgejo-runner's self-assert, phoenixd's timer enable, mempool's three timer enables, fulcrum's restart handler and bitcoind's restart handler. Every guard was read and asked "monitoring or deployment?" before being deleted, which is the only reason this was caught. ── What was removed ──────────────────────────────────────────────────────── 30 uptime_kuma_enabled guards across 7 unconverted service playbooks, and the 29 Kuma monitor-creation tasks they gated (embedded Python that drove the Kuma API, temp credential files, cleanup) 7 dead uptime_kuma_api_url definitions 7 stale DEPRECATED banners uptime_kuma_enabled and subdomains.uptime_kuma from group_vars/all healthcheck_push_urls from the vault - 30 push tokens services/ntfy/setup_ntfy_uptime_kuma_notification.yml -> archive/ The explanatory comments in the six converted roles are KEPT on purpose. They record why a handler is ungated, and deleting the explanation invites someone to helpfully re-add the guard. ── The probes moved rather than died ─────────────────────────────────────── Eight per-service health checks were still pushing to Kuma. They are not superseded by infra/401: that answers "is the unit running", these answer "does the service actually respond" - an RPC call to bitcoind, a TCP connect to Fulcrum's Electrum port, an HTTP fetch from Mempool's backend. A process can be perfectly `active` and useless. So they were repointed, not deleted. Gatus external endpoints take a POST with a bearer token and success=true\|false where Kuma took a GET with ?status=up, so report() now maps up/down to true/false internally and no call site changed. Registered by infra/403 as the `probe` group, one token per host. Two bugs fixed while in there: * forgejo-runner's check only ever reported SUCCESS - it exited before pushing when the runner was down, so a failure was invisible until the heartbeat window expired. Reporting the failure is the entire point of a check. * All six healthcheck .service units were mode 0644 and now carry a bearer token. They are 0600. Verified: 91 endpoints, 91 UP, 0 DOWN. Every probe triggered by hand and confirmed arriving. Zero Kuma URLs left in the vault, zero live references in any playbook or role. Still standing, deliberately: the Kuma container on watchtower, its Caddy vhost, and the uptime.contrapeso.xyz DNS record. Turning the service off is a separate decision from removing the code that talked to it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> 2026-09-14 10:30:28 +02:00			`Environment=HEALTHCHECK_PUSH_URL={{ healthcheck_push_url }}`
			`Environment=HEALTHCHECK_PUSH_TOKEN={{ healthcheck_push_token }}`
forgejo-runner: convert to a role, de-Uptime-Kuma the health check 409-line playbook becomes a 16-line playbook plus a 318-line role with phases split across tasks/{prerequisites,install,configure,service,healthcheck}.yml and four templates. forgejo_runner_vars.yml is deleted; its content is the role's defaults. Applies the Plan 6 Stage 0 decision: keep whatever determines whether the service is healthy, drop the Uptime Kuma specifics, make the reporting point pluggable. Gone from the role: the embedded Python that created monitors over the Kuma API, the /tmp credentials file, token extraction, the systemd Environment= rewrite, and 8 `when: uptime_kuma_enabled` guards. What remains is the check itself, its log, the systemd unit and timer, and an honest exit code - `systemctl is-failed forgejo-runner-healthcheck.service` now answers the question with no monitoring system involved at all. Reporting is one variable, healthcheck_push_url, empty by default. Any endpoint that accepts an HTTP ping plugs in there. A pull-based monitor wants it left empty and reads unit state instead. PREMISE CORRECTION: Uptime Kuma is NOT dead. Plan 3 recorded "48 push timers curling an endpoint that no longer answers" and Plan 6 said the check had "nowhere to report to". Both wrong - 24+ push scripts across 11 hosts are pushing successfully right now (HTTP 200). Only the Ansible code and the vault credentials were decommissioned; the service never stopped. So the existing push URLs were harvested into a vaulted healthcheck_push_urls dict and are preserved, keeping this refactor behaviour-neutral. Retiring Kuma stays a deliberate act rather than a side effect. PLAN_3 and PLAN_6 are corrected. Verified: - task-list diff vs the old playbook shows ONLY the five Kuma tasks removed, everything else identical and in the same order - first run ok=22 changed=1 (the rewritten health script); both systemd units and forgejo-runner.service came back ok, so the templates reproduce the previous files byte-for-byte - second run ok=22 changed=0, fully idempotent - still reports "Ping sent successfully (HTTP 200)" from a script containing zero Uptime Kuma references - the 4 skipped tasks are genuine already-configured guards, checked not assumed Two things for the next service: - import_tasks, not include_tasks. Dynamic includes are opaque to --list-tasks, which is the primary verification tool here; the first attempt produced a useless diff. - `Assert runner is running` was guarded by uptime_kuma_enabled and so had not run since the decommissioning. It is not monitoring, it is the deployment checking its own work - the deprecation banner swept it up with the Kuma plumbing, and a runner that failed to start was deploying "successfully" in silence. Ungated now. The banner was applied to contiguous blocks, so read every uptime_kuma_enabled guard and ask whether it is monitoring or deployment. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> 2026-09-12 18:15:29 +02:00			`User=root`
			`StandardOutput=journal`
			`StandardError=journal`

			`[Install]`
			`WantedBy=multi-user.target`