Monitoring endpoints & health checks
Purpose: The URLs and MBeans that tell you an instance is healthy, for wiring into load balancers and monitoring.
Who this page is for
| Audience | Why it matters to you |
|---|---|
| Platform engineers | Monitoring wiring |
| Backend engineers | What "healthy" means |
Liveness vs readiness (yes, the k8s distinction applies)
| Check | Endpoint | Use |
|---|---|---|
| Process up | TCP :4502/:4503 | Basic liveness |
| Sling ready | /system/health (Sling Health Checks, configurable tags) | Readiness gates |
| Bundles all active | /system/console/bundles.json (count Installed/Resolved) | Deploy verification |
| Replication queues | JMX com.adobe.granite.replication agent MBeans (queue size, blocked) | Author alerting |
| Repository | JMX Oak MBeans (SegmentNodeStore stats, revision GC status) | Capacity trends |
| Login works end-to-end | Synthetic login + page render probe | The only check users care about |
| Publish render | GET a known page with expected string | LB health check target |
Sling Health Checks are extensible — write custom HCs for your integrations (e.g. "premium API reachable") and tag them into /system/health?tags=phi; one endpoint then aggregates platform + app health.
Load balancer guidance
- LB health check against a real rendered page through the dispatcher (e.g. a lightweight
/health.htmlpage that exercises render + repo read), not just a TCP check — publishers can be up but sick. - Take a publisher out of rotation before deploying to it; health checks flapping during deploys cause user-visible errors.
What to alert on vs observe
Alert: blocked replication queue, bundles not active after deploy, health check red, disk >80%, error.log ERROR rate spike. Observe (dashboards): cache hit ratio, render p95, workflow backlog, repo size trend, GC pauses. Full operational picture: Monitoring & alerting.