
<h1 id="ci-monitoring">CI Monitoring <span style="display:inline-flex;align-items:center;vertical-align:middle;padding:2px 10px;font-size:14px;font-weight:700;border-radius:9999px;background:linear-gradient(135deg,#6366f1,#8b5cf6);color:white;letter-spacing:0.05em;position:relative;top:-2px;margin-left:6px;">PRO</span></h1>

CI Monitoring is about filtering CI runs down to the ones that actually came from work on your machine.

Today this works with `GitHub Actions`. `GitLab` support is planned next.

## Built On Pro CI Actions

Triggering CI workflows is part of DevKeepr Pro more broadly. When DevKeepr detects a supported provider on a project, workflow actions can show up anywhere the app surfaces those project actions.

CI Monitoring builds on top of that. After you trigger a workflow or push changes from your machine, DevKeepr can keep the resulting runs in view without sending you back to your provider's dashboard.

## Only See The Runs You Care About

The useful part is not just dispatching workflows. DevKeepr also knows when you push from your machine.

That means it can correlate your local Git activity with the workflow runs your provider starts afterward, and surface the runs that belong to what you are working on right now. Instead of a noisy feed of every run across every branch, you get the runs that were triggered by your own actions.

This is especially useful on busy repositories where multiple people are pushing all day. You can ignore unrelated CI noise and stay focused on your branch.

## Cut Through Notification Noise

Because the relevant workflow runs are already visible in DevKeepr, you do not need provider notifications constantly pulling your attention away.

You can turn off the notification firehose and still keep a close eye on your own builds, checks, and deploy pipelines. DevKeepr surfaces the runs that matter to the project you are actively touching, so the signal stays high.

## Where Runs Show Up

Workflow runs appear in two places:

- **Project detail panel** for a project-scoped view of the runs tied to that repo
- **Process tray** for a unified view alongside local scripts and other running work

That means you can stay in the app while a workflow is queued, running, or failing, without context-switching back to your provider.

![Workflow run expanded in the tray showing job and step progress](/screenshots/docs/workflow-run.webp)

## Drill Into Progress

Each workflow run includes live status updates, so you can quickly see whether it is queued, in progress, completed, or failed.

Expand a run to inspect its jobs and steps, see where it failed, and jump straight to the provider only when you actually need the full web view.

See [Process Tray](/docs/general/features/process-tray) for more on how workflow runs are presented in the tray.
