Health Check Endpoints
Tines Stories exposes two unauthenticated endpoints on the tines-app container that you can use for load balancer health checks, container probes, and uptime monitoring. Both are served on the web server port (3000 by default) and through your load balancer.
Each request to either endpoint checks that the application can reach:
PostgreSQL
Redis
At least one running Sidekiq process
Because the checks include Sidekiq, a failure doesn't always mean the tines-app container itself is unhealthy. If tines-sidekiq is stopped or still starting, both endpoints report a failure.
/health
Returns the result of each check as JSON. It always responds with a 200 status code, even when a check fails, so read the healthy field rather than the status code.
curl https://<your-tines-domain>/healthSample response
{"healthy": false,"errors": {"db": null,"redis": null,"sidekiq": "Sidekiq return zero processes"},"version": "v44.0.1"}/is_up
Returns 200 when all checks pass and 500 when any check fails. The response has no body. When a check fails, the error is written to the tines-app container logs.
curl -i https://<your-tines-domain>/is_upWhich endpoint to use
/health returns 200 as long as the web server is responding, which makes it suitable for liveness and startup probes. Using /is_up for a liveness probe means an outage in PostgreSQL, Redis, or tines-sidekiq can cause your orchestrator to restart tines-app containers that are otherwise healthy.
Related
System diagnostics runs a broader set of checks from inside the app.
Infrastructure metrics covers alerting on your load balancer's unhealthy host count.