Pipelines (VCS & CI/CD Observability)

Pipelines connects your version control and CI/CD providers to KubeWatch so that pushes, pull requests, pipeline runs, and deploys show up alongside the infrastructure metrics you're already watching. It's available on the Pro and Enterprise plans, and every new account also gets it automatically during the 30-day trial. See Plans & Pricing.

What it does

Once a provider is connected, KubeWatch ingests three kinds of records:

• Code events: pushes, PR opens/merges, tags, and releases.
• Pipeline runs: CI/CD executions, each broken down into stages (build, test, deploy, ...).
• Deployment markers: a record of what actually got deployed where, and when.

Beyond connecting providers and browsing that data, KubeWatch also correlates it with the rest of the platform: deployment markers overlay directly on the Kubernetes dashboard's namespace charts, and dedicated alert rules watch pipeline health and post-deploy regressions.

Connecting a provider

Open Connections under Pipelines in the sidebar and click Add connection. Pick a provider, then the wizard adapts based on which of three tiers it belongs to.

Kubernetes-native providers (no credentials)

Argo CD, Flux, and Tekton run inside your cluster, and the KubeWatch Agent's existing ClusterRole already has read access to the resources each one manages (Application, Kustomization/HelmRelease, PipelineRun/TaskRun). Picking one of these skips credential entry entirely: you just confirm the target (a namespace or app name) and save. There's nothing to test against an external API, since the Agent already has the access it needs.

SaaS and self-managed CI/VCS providers (token-based)

GitHub, GitLab, Bitbucket (Cloud and Server/Data Center), Azure DevOps, CircleCI, and Jenkins each poll their own REST API on an interval you choose (1 minute to 1 hour). The wizard asks for whatever that provider needs: a personal access token for most, plus a base URL for self-managed instances (GitLab, Jenkins, Bitbucket Server, Azure DevOps). Click Test connection to validate the credentials before saving. Save connection stays disabled until a test has been attempted.

Generic / anything else

For a provider not listed above, the Generic option offers a Git remote poller: point it at any git remote URL and KubeWatch runs git ls-remote on an interval, emitting a code event whenever a ref changes. VCS-only, no CI/CD data.

Real-time delivery (webhooks)

Polling (1 minute to 1 hour, whatever interval you chose) is the default and always works: it needs no inbound connectivity, so it's the only option guaranteed to work behind a corporate firewall. GitHub, GitLab, Bitbucket Cloud, Azure DevOps, and CircleCI additionally support real-time webhook delivery on top of polling, trimming latency from "up to your poll interval" down to a few seconds.

To turn it on, open a connection's row on the Connections page and click Enable webhook. KubeWatch generates a URL and a secret, shown to you exactly once. Copy both immediately:

• Paste the webhook URL into the provider's own webhook settings (e.g. GitHub repo settings → Webhooks → Add webhook).
• Paste the secret into whatever field that provider uses to sign or authenticate the payload (a signing secret for GitHub/CircleCI, a token field for GitLab, a custom header value for Bitbucket Cloud/Azure DevOps).

The Jenkins / Tekton deploy-detection convention

Neither Jenkins nor Tekton has a native concept of "this run changed what's running": a pipeline stage is just a stage until you tell KubeWatch which ones represent an actual deploy. For these two providers specifically, the connection wizard adds one more field: a comma-separated list of stage (Jenkins) or task (Tekton) names, e.g. deploy, deploy-prod. This is a one-time, per-connection setting, not something KubeWatch tries to infer automatically.

Viewing pipeline runs and code events

Pipeline Runs lists every run ingested so far, with status, trigger type, duration, and which connection it came from. Filter by status or connection, and click through to a run's detail page for its stage-by-stage timeline (each stage shown as a colored, duration-proportional bar).

A View logs button next to a stage (GitLab, CircleCI, Tekton) or next to the run's own status (Jenkins, GitHub Actions, which don't report a per-stage breakdown) opens the real build output, fetched live from that provider's own log API using the credentials already on the connection. Tekton logs come straight from the underlying Pod via your connected agent. The log view keeps refreshing while a build is still running, so it never looks like it froze partway through.

Code Events is a reverse-chronological feed of pushes, PRs, tags, and releases, with provider and repo/scope filters sourced from your connections.

Managing connections

Each row on the Connections page shows a health badge derived from recent poll activity: healthy, N failing if the last several polls errored, or disabled if you've turned it off. From there you can:

• Test: re-validate the already-saved credentials against the provider.
• Edit: enable/disable the connection, change its poll interval, or turn webhook delivery on/off.
• Delete: remove the connection (a confirmation step first). Code events and pipeline runs already recorded aren't deleted with it.

Deployment markers on your charts

When a deploy lands (a pipeline run that actually changes what's running in a namespace, or an Argo CD/Flux sync), it shows up as a dashed vertical line directly on the Kubernetes dashboard's per-namespace CPU and memory charts. Filter the dashboard to a specific namespace to see them. Hover a marker for the commit and version tag, or click it to jump to that deploy's pipeline run detail, when one exists (a manual Argo CD/Flux sync has no associated pipeline run to link to).

Alerting on pipeline health and deploy regressions

Five new alert rule types are available wherever you already create alert rules, under Alerts:

• Pipeline Failed: fires the moment a pipeline run's terminal status is failed.
• Pipeline Stuck: fires when a run has been running longer than a threshold you set, in minutes.
• Pipeline Flaky: fires when the same pipeline/branch alternates between passing and failing more than a threshold number of times across its last 10 runs, a leading indicator of an unreliable test suite.
• Deploy Regression: the correlation rule. Pick a metric to watch (e.g. container_cpu_percent) and a percent-increase threshold. KubeWatch compares that metric's average in the 15 minutes before and after a deploy, and fires if it jumped by more than your threshold. This is what turns "CPU spiked" into "CPU spiked right after this deploy."
• VCS Connector Unhealthy: fires when a connection's consecutive poll/webhook failures cross a threshold, so a silently-broken integration doesn't just show an empty Pipelines page with no explanation.

A Deploy Regression alert can also trigger an automatic rollback: attach a Roll back Kubernetes Deployment Autonomous Remediation playbook to the rule, and KubeWatch reverts the Deployment to its previous revision the moment a regression fires. This works end-to-end today for an Argo CD Application managing exactly one Deployment. Flux, Tekton, and CI/CD-provider deploys still fire the alert, but they can't be an automatic rollback's trigger yet, since their deployment markers don't name a specific Deployment.