Hangar

SDLC · Stage 06 of 07

Operate and observe

You should be able to follow any change from start to finish in one place, and trust the numbers you see.

Principles: Event-driven by default, Interfaces people trust

When something goes wrong at 2 a.m., the platform should help you understand what happened, not make you piece it together from five different tools.

Every pipeline step emits an OpenTelemetry span, and the spans are stitched into one Tempo trace per end-to-end flow, even though each stage is a separate PipelineRun. Grafana shows the live and historical pipeline list, a per-stage drill-down and DORA metrics computed from the CDEvents stream. MTTR is shown as experimental, because a rollback done outside the pipeline is a blind spot that would otherwise make it quietly wrong.

Run history is archived with Tekton Results; stalled pipelines are detected and alerted on; old runs are pruned. Tower brings it together for the people running services: releases per environment, rollout topology, SLO burn rates and fleet-wide views.

When a rollout degrades, the control plane itself asks for a diagnosis and comes back with a fix PR.

Where Hangar does this

Architecture · 01 of 07 · System overviewGlidepath end to end: from a push to a verified releaseOpen full page ↗

And for AI agents

A flight recorder for agents, and alerts that arrive with a tested hypothesis

Agent observability reuses the same telemetry and adds one tamper-evident, hash-chained audit trail. Triage moves from a bespoke integration to a bounded agent behind Clearance, and remediation earns autonomy one alert class at a time.

Data flow · 15 of 19 · Flight recorderFlight recorder: reuse the telemetry, add one tamper-evident chainOpen full page ↗
Swimlane · 09 of 10 · RemediationAlerts that resolve themselves, or page with a tested hypothesisOpen full page ↗
Architecture · 17 of 19 · AI triageAI triage: move Holmes's GitHub access behind ClearanceOpen full page ↗

The full Autopilot walkthrough →