CI/CD Pipelines
Pipelines shows the CI/CD runs HostAtlas has ingested from your build system, alongside the servers and deploys each run produced. It’s the bridge between “a green build merged at 14:03” and “the server started paging at 14:07.”
What you see
Section titled “What you see”Under Pipelines in the sidebar. Each row is a pipeline run:
- Provider (GitHub Actions, GitLab CI, Bitbucket Pipelines, Buildkite, Jenkins, or a generic webhook source).
- Repository and branch / ref.
- Run number, status (queued, running, success, failed, cancelled).
- Actor — who pushed or clicked “run”.
- Duration.
- Linked deploys and affected servers.
Filters: provider, repo, status, actor, date range.
What you can do
Section titled “What you can do”- Open a pipeline run to see the ingested payload — headers, JSON body, stages if the provider sends them — plus the deploy records and servers linked to it.
- Follow the correlation trail — from a pipeline run to its deploy, from the deploy to the server, from the server to any incident that opened after.
- Filter to failed runs to spot flaky pipelines that never actually deploy.
How it works
Section titled “How it works”- Pipelines are ingested via inbound webhooks. Each provider has its own signed webhook endpoint under Settings; drop the URL into your CI provider’s outgoing-webhook config and pick which events to send (queued / started / completed is the useful set).
- When a run completes, HostAtlas matches it against a deploy event (by SHA, tag, or explicit correlation ID) and attaches the two.
- The correlation is one-way informational — HostAtlas does not trigger, cancel, or retry pipelines in your CI system.