Observability
Unified observability for Argo Workflows: runs, logs, and metrics in one place.
Last updated
Unified observability for Argo Workflows: runs, logs, and metrics in one place.
Argo Workflows runs reliably; finding and debugging individual runs across many namespaces, clusters, and teams is the problem. Pipekit gives every Argo Workflow a Pipekit-side Pipe and Run, aggregates them into one UI, and persists their state and logs beyond the lifetime of the underlying Kubernetes objects.
Submit from the CLI, the UI, a Git event, or a cron schedule. Every Run lands in the same Pipes view. Externally triggered Workflows submitted to your cluster outside Pipekit (via kubectl, Argo CLI, or Argo Events) can also be surfaced in Pipekit, so you can migrate to Pipekit without losing visibility into existing pipelines.
Argo deletes completed pods on its own schedule. Pipekit captures Run status, the workflow node graph, pod logs, workflow logs, and the submitted YAML when the Run starts, and keeps them indefinitely.
Pipekit auto-detects log levels from common formats (JSON, logfmt, syslog, bracketed, timestamp-prefixed) and color-codes them inline. You can filter by container, search across a Run with regex, and pivot from a failing pod to its workflow node graph in one click. For the full list of supported log formats, see Pod Logs > Log Level Detection.
By default Pipekit hosts your logs. If you'd rather keep them in your existing stack, point the Pipekit Agent at your S3 / object storage and Pipekit will read from there. See BYO Logging Backend.
Pipekit collects OpenTelemetry workflow metrics from each registered Cluster and surfaces them as dashboards. You see queue depth, scheduling latency, success and failure rates, and pod resource use per Pipe, without instrumenting your workflows. See Metrics & Alerts.
Last updated