---
title: Health Check Endpoints
url: https://www.tines.com/stories/docs/self-hosted/monitoring-tines/health-check-endpoints/
updated: 2026-10-23T19:56:49+00:00
---

*[tines.com](https://www.tines.com/llms.txt) › [Docs](https://www.tines.com/stories/docs/llms.txt) › [Self-Hosted](https://www.tines.com/llm/stories/docs/self-hosted.md) › [Monitoring Tines](https://www.tines.com/llm/stories/docs/self-hosted/monitoring-tines.md)*

# Health Check Endpoints

*[View on tines.com](https://www.tines.com/stories/docs/self-hosted/monitoring-tines/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>/health
```

#### Sample response

```
{"healthy": false,"errors": {"db": null,"redis": null,"sidekiq": "Sidekiq return zero processes"},"version": "v44.0.1"}
```

| Field | Description |
| --- | --- |
| `healthy` | `true` if every check passed. |
| `errors` | One entry per check: `db`, `redis`, and `sidekiq`. `null` means the check passed; otherwise the value is the error message. |
| `version` | The Tines Stories version running in this container. |

### `/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_up
```

### Which endpoint to use

| Use case | Endpoint |
| --- | --- |
| Load balancer target group health check | `/is_up` |
| Kubernetes readiness probe | `/is_up` |
| Kubernetes liveness or startup probe | `/health` |
| Uptime monitoring and alerting | `/is_up` |
| Finding out which dependency is failing | `/health` |

`/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](https://www.tines.com/docs/self-hosted/troubleshooting/system-diagnostics) runs a broader set of checks from inside the app.
- [Infrastructure metrics](https://www.tines.com/docs/self-hosted/monitoring-tines/infrastructure-metrics) covers alerting on your load balancer's unhealthy host count.