> ## Documentation Index
> Fetch the complete documentation index at: https://docs.lerian.studio/llms.txt
> Use this file to discover all available pages before exploring further.

# Observability in Flowker

> Configure Flowker telemetry and use its health endpoints and execution records to operate workflows.

Flowker can emit OpenTelemetry data for its HTTP and service operations. Telemetry is opt-in: enable it in the deployment, send it to your collector, and use the execution API for workflow-specific status and results.

## Enable and export telemetry

***

Set these environment variables in the Flowker deployment:

```bash theme={null}
ENABLE_TELEMETRY=true
OTEL_EXPORTER_OTLP_ENDPOINT=https://your-otlp-collector.example:4317
```

With telemetry enabled, Flowker initializes its telemetry instruments and exports through the configured OTLP endpoint. You do not add instrumentation to individual workflows, but the deployment must provide a reachable collector. Use an `https://` endpoint for a remote collector. Reserve a plaintext `http://` endpoint for a collector that is local to the host or reachable only over an isolated network. Flowker does not provision Grafana dashboards, retention, or alert rules. Those are decisions in your observability platform.

## Check service health

***

Flowker exposes Kubernetes-compatible probes. The `GET /health` endpoint is a liveness check. After its startup self-probe passes, it returns `200 healthy` and deliberately does not call the database, cache, or downstream services. The `GET /readyz` endpoint is the readiness check for dependencies. Use it when you need to know whether Flowker can serve requests now.

## Use your observability platform

***

Route the OTLP stream to the backend your platform operates, such as Grafana, and build dashboards and alerts there. Keep those dashboards separate from execution investigation: API request telemetry does not replace the execution record.

For an individual workflow run, use [Get execution results](/en/reference/products/flowker/get-execution-results) to see its status, step results, and final output when present. A failed step can include an `errorMessage`. This response has no top-level error-details field.

## How to interpret execution status

***

Each workflow execution in Flowker has a status that tells you where it stands.

| Status      | Meaning                                                                                                                                                                                  | What to do                                                                                                |
| ----------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------- |
| `pending`   | The execution has been created but has not started. In the normal execution path, Flowker changes it to `running` synchronously before responding; do not treat it as a scheduler queue. | —                                                                                                         |
| `running`   | Execution is in progress                                                                                                                                                                 | Normal — monitor for completion                                                                           |
| `completed` | All steps finished successfully                                                                                                                                                          | No action needed                                                                                          |
| `failed`    | Execution finished with an error                                                                                                                                                         | Check `stepResults` for a failed step. A failure before any step runs has no step error in this response. |

<Tip>
  If you see a significant number of `failed` executions in a short period, collect their execution ids and error details before you escalate.
</Tip>

## When to involve engineering

***

Escalate to engineering when:

* `GET /readyz` reports a dependency as down
* the OTLP collector is unreachable or rejects the telemetry stream
* `failed` executions exceed the alert threshold your deployment defines and the cause is not clear
* Flowker does not process new executions while readiness is successful

Share the execution ids, UTC timeframe, relevant API error payloads, and the `/readyz` response. With telemetry enabled, include the collector or dashboard link as supporting evidence.