Skip to main content
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:
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 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.
If you see a significant number of failed executions in a short period, collect their execution ids and error details before you escalate.

​
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.