# ADR-0004: Reuse the monylog stack for ops monitoring (not Uptime Kuma)

**Status:** Accepted — 2026-07-15

## Context

An earlier note proposed deploying Uptime Kuma in-cluster. Inspection showed the homelab already
runs **monylog** (`10.66.15.21`, Ansible role `pglta`): a full self-hosted LGTM + Alertmanager
stack (Prometheus, Grafana, Loki, Tempo, Alertmanager → Pushover/ntfy → phone), deliberately
**external to k8s** so it alerts even when the cluster is down. Grafana Alloy (k3s DaemonSet)
already remote-writes cluster metrics (incl. kube-state-metrics) and ships all pod logs to
monylog Loki.

## Decision

**Reuse monylog; do not deploy Uptime Kuma or any new alerting channel.** BlueCap pod/deployment
metrics and nginx logs already flow in. Add only:

1. `blackbox_exporter` to the monylog compose + a Prometheus scrape job probing the in-cluster
   Service (app health) and the public URL (edge-path uptime + TLS expiry).
2. A `web-bluecap.yml` alert rules file (SiteDown, CertExpiringSoon <14d, High5xx,
   DeploymentDegraded, PodRestarting).
3. A `service: bluecap` label so Alertmanager routes to existing Pushover; a Grafana dashboard.

## Consequences

- No duplicate monitoring/alerting infra; one pane of glass, alerts already reach the phone.
- Changes land in the Homelab Ansible repo (`roles/monylog`), not this repo.
- monylog being off-cluster gives a genuine external vantage for public-URL probing.
- Detail in `docs/seo-aeo-optimization.md` §6a and `docs/gitops-deployment-strategy.md` §4.3.