-
Type:
Suggestion
-
Resolution: Unresolved
-
None
-
Component/s: Data Center - Deployments
-
None
-
1
Enhancement to the Confluence Data Center status endpoint:
- Endpoint:
http://<confluenceurl>/status
- Documented here:
[Confluence Data Center Technical Overview | Enterprise Data Center Latest | Atlassian Documentation|https://confluence.atlassian.com/enterprise/confluence-data-center-technical-overview-612959401.html]
Current behavior
As documented, the /status endpoint indicates whether Confluence is running as a service on the application server. In our environment, this behaves as a basic liveness check:
- When Confluence has started and is in the RUNNING lifecycle state, /status returns:
-
- HTTP 200 OK
-
- Body: {{
{"state":"RUNNING"}
}}
- Body: {{
{"state":"RUNNING"}
This shows that /status is not sufficient as a load balancer health check in real-world failure scenarios where the JVM/Tomcat process is still up but the node is effectively unusable for users.
Suggested Improvement
- Enhance the existing /status endpoint
Add deeper health checks behind /status so that it can:
-
- Detect when the node is in a degraded state where typical Confluence web requests are failing (e.g. persistent HTTP 5xx).
-
- Return a non‑2xx HTTP status or a state such as "ERROR" in those situations, rather than always returning "RUNNING" as long as the process is up.
- Or, provide a new official “readiness” / “deep health” endpoint
-
- Document a separate endpoint specifically designed for load balancer health checks in Confluence Data Center.
-
- This endpoint would:
-
-
- Perform minimal but meaningful application-level checks (e.g. routing, core plugin health).
-
-
-
- Return a failing HTTP status when the node is not actually usable by end users, even if the process is still running.
-
-
- Keep /status as a lightweight liveness endpoint, but recommend the new endpoint for LB health checks in Data Center deployments.
Main goal is to have a supported, documented endpoint that:
- Can safely be used by load balancers and monitoring systems.
- Accurately reflects when a node should be taken out of rotation because it is no longer serving user requests successfully.