home / skills / thebushidocollective / han / monitor-pipeline

This skill monitors a GitLab pipeline or job in real time, reporting status changes and failures until completion.

npx playbooks add skill thebushidocollective/han --skill monitor-pipeline

Review the files below or copy the command above to add this skill to your agents.

Files (1)
SKILL.md
7.0 KB
---
name: monitor-pipeline
description: Monitor a GitLab pipeline or job until completion, reporting status changes and failures in real-time
---

# Monitor GitLab Pipeline

## Name

gitlab:monitor-pipeline - Monitor a pipeline or job until completion with real-time status updates

## Synopsis

```
/monitor-pipeline <project-id> <pipeline-id> [--job <job-id>] [--interval <seconds>]
```

## Description

Continuously monitors a GitLab CI/CD pipeline or specific job until it reaches a terminal state (success, failed, or canceled). Reports status changes as they happen and immediately notifies the user of any failures with detailed error information.

## Implementation

This skill uses a polling approach to monitor pipeline and job statuses:

1. **Initial Status Check**: Fetch current pipeline/job state
2. **Polling Loop**: Check status at regular intervals (default: 15 seconds)
3. **Change Detection**: Compare current state with previous state
4. **Real-time Reporting**: Output updates when jobs transition states
5. **Failure Notification**: Immediately report failures with job logs
6. **Completion**: Exit when pipeline reaches terminal state

### Monitoring Algorithm

```
WHILE pipeline.status IN [pending, running, waiting_for_resource, preparing]
  WAIT interval seconds
  FETCH current pipeline status
  FETCH all job statuses

  FOR each job:
    IF job.status changed:
      REPORT status change
      IF job.status == "failed":
        FETCH job logs
        REPORT failure details immediately

  REPORT overall progress summary

REPORT final pipeline result
```

## Usage

### Monitor a Pipeline

```
/monitor-pipeline 456 1234
```

### Monitor a Specific Job

```
/monitor-pipeline 456 1234 --job 5678
```

### Custom Polling Interval

```
/monitor-pipeline 456 1234 --interval 30
```

## What This Skill Does

1. **Fetches initial pipeline state** using GitLab API
2. **Tracks job transitions** from pending -> running -> success/failed
3. **Reports immediately** when any job fails
4. **Fetches failure logs** automatically for failed jobs
5. **Provides progress updates** showing completed vs remaining jobs
6. **Exits cleanly** when pipeline completes or is canceled

## Prerequisites

- GitLab MCP server must be configured
- Access to the target project
- Valid pipeline ID (can be obtained from MR or project pipelines list)

## Example Interaction

### Successful Pipeline Monitoring

```
User: /monitor-pipeline 456 1234

Claude: Starting pipeline monitor for Pipeline #1234 in project 456...

## Pipeline Monitor Started

**Pipeline**: #1234
**Branch**: feature/add-authentication
**Started**: 2025-01-15 10:30:22
**Status**: Running

I'll monitor this pipeline and report status changes as they happen.

---

### Update [10:31:45]

**Stage: build**
- ✓ `compile` completed successfully (1m 18s)

Progress: 1/6 jobs complete

---

### Update [10:32:30]

**Stage: build**
- ✓ `bundle-assets` completed successfully (42s)

Progress: 2/6 jobs complete

---

### Update [10:34:15]

**Stage: test**
- ✓ `unit-tests` completed successfully (1m 45s)

Progress: 3/6 jobs complete

---

### Update [10:36:00]

**Stage: test**
- ✓ `integration-tests` completed successfully (1m 45s)

Progress: 4/6 jobs complete

---

### Update [10:37:30]

**Stage: lint**
- ✓ `eslint-check` completed successfully (1m 30s)
- ✓ `type-check` completed successfully (1m 28s)

Progress: 6/6 jobs complete

---

## Pipeline Complete

**Status**: ✓ Success
**Total Duration**: 7m 08s
**All 6 jobs passed**

The pipeline completed successfully. Your changes are ready for merge.
```

### Pipeline with Failure

```
User: /monitor-pipeline 456 1234

Claude: Starting pipeline monitor for Pipeline #1234...

## Pipeline Monitor Started

**Pipeline**: #1234
**Branch**: feature/database-migration
**Status**: Running

---

### Update [10:31:45]

**Stage: build**
- ✓ `compile` completed successfully (1m 18s)

Progress: 1/6 jobs complete

---

### FAILURE ALERT [10:33:20]

**Job Failed**: `integration-tests` in stage `test`

**Duration**: 1m 35s
**Exit Code**: 1

**Error Log**:
```
FAILED tests/integration/auth.test.ts

  ● Authentication API › POST /login › should validate credentials

    ConnectionError: Connection to database refused
    at PostgresClient.connect (src/db/client.ts:45:12)
    at setupTestDB (tests/setup.ts:23:8)

  1 test failed, 12 passed
```

**Likely Causes**:
1. Database service not available in CI environment
2. Missing DATABASE_URL environment variable
3. Network connectivity issues in test container

---

## Pipeline Failed

**Status**: ✗ Failed
**Duration**: 3m 35s
**Failed Jobs**: 1 (integration-tests)
**Passed Jobs**: 2
**Canceled Jobs**: 3

The pipeline failed due to test failures. Review the error above and push a fix.

Would you like me to help debug the database connection issue?
```

### Monitoring a Specific Job

```
User: /monitor-pipeline 456 1234 --job 5678

Claude: Starting job monitor for Job #5678 (deploy-production)...

## Job Monitor Started

**Job**: deploy-production (#5678)
**Stage**: deploy
**Status**: Running
**Started**: 2025-01-15 14:30:00

---

### Progress [14:31:00]

```
Deploying to production cluster...
- Pulling latest images... done
- Running database migrations... done
- Starting new containers...
```

---

### Progress [14:32:30]

```
- Health checks passing (3/3 replicas)
- Draining old instances...
- Deployment complete!
```

---

## Job Complete

**Status**: ✓ Success
**Duration**: 2m 45s

Production deployment successful!
```

## Arguments

| Argument | Required | Description |
|----------|----------|-------------|
| `project-id` | Yes | Numeric project ID or URL-encoded path |
| `pipeline-id` | Yes | Pipeline ID to monitor |
| `--job` | No | Specific job ID to monitor instead of entire pipeline |
| `--interval` | No | Polling interval in seconds (default: 15, min: 5, max: 300) |

## Terminal States

The monitor exits when the pipeline/job reaches one of these states:

| State | Description |
|-------|-------------|
| `success` | All jobs completed successfully |
| `failed` | One or more jobs failed |
| `canceled` | Pipeline was manually canceled |
| `skipped` | Pipeline was skipped (rules not met) |

## Status Indicators

| Icon | Meaning |
|------|---------|
| ✓ | Success/Passed |
| ✗ | Failed |
| ⏳ | Running |
| ⏸️ | Pending/Waiting |
| ⏭️ | Skipped |
| ⊘ | Canceled |

## Tips

- Use shorter intervals (5-10s) for quick pipelines
- Use longer intervals (30-60s) for long-running deployments
- Monitor specific jobs when you only care about one stage
- The skill automatically fetches logs for failed jobs
- Cancel monitoring with Ctrl+C if needed

## Error Handling

- **API Errors**: Retries with exponential backoff
- **Network Issues**: Reports connection problems, continues monitoring
- **Invalid IDs**: Exits immediately with helpful error message
- **Permission Denied**: Reports access issue, suggests checking permissions

## Related Commands

- `/view-pipeline`: One-time snapshot of pipeline status
- `/create-mr`: Create MR that triggers a pipeline
- `/review-mr`: Review MR including pipeline status

Overview

This skill monitors a GitLab pipeline or a specific job until it reaches a terminal state, delivering real-time status updates and failure notifications. It continuously detects job transitions and reports them as they happen, fetching logs immediately if a job fails. The monitor exits cleanly when the pipeline or job completes, fails, is canceled, or is skipped.

How this skill works

The skill polls the GitLab API at a configurable interval (default 15s) to fetch pipeline and job states. It compares current job statuses to the previous snapshot and emits updates for any transitions. On failures it retrieves job logs and error details and reports them immediately. It handles API errors with retries and exits when a terminal state is reached.

When to use it

  • Track progress of a CI/CD pipeline in real time during a merge or release.
  • Watch a single critical job (deploy, migration, or tests) to know success/failure instantly.
  • Get immediate failure logs when flaky tests or environment issues occur.
  • Monitor long-running deployments with lower-frequency polling to conserve API quota.
  • Alert team members during a release window about pipeline progress and failures.

Best practices

  • Use shorter intervals (5–10s) for short fast pipelines and longer intervals (30–60s) for long-running deployments to limit API calls.
  • Monitor a specific job when you only care about a single stage to reduce noise and speed up failure detection.
  • Ensure the API token has project access; permission errors are reported and monitoring stops.
  • Rely on automatic log fetch for failures to save time debugging; copy the error excerpt into your issue or MR.
  • Cancel the monitor (Ctrl+C) if you no longer need live updates; use one-time snapshot commands for periodic checks.

Example use cases

  • Live-track a feature branch pipeline to know when it is safe to merge after CI passes.
  • Watch the deploy-production job to confirm a production rollout completes successfully.
  • Detect test failures immediately and fetch the failing test logs to triage flaky tests faster.
  • Monitor an integration pipeline that depends on external services to spot environment connectivity issues.
  • Use longer interval monitoring for blue/green or canary deployments to reduce API overhead.

FAQ

How do I change the polling interval?

Pass --interval <seconds> when invoking the monitor (default 15s, min 5s, max 300s). Use shorter values for fast feedback and larger for long-running jobs.

Can I monitor only one job?

Yes. Use --job <job-id> to watch a single job instead of the entire pipeline; the monitor will stream that job’s logs and status.

What happens on permission or API errors?

The skill reports permission or API problems, retries transient failures with exponential backoff, and exits on persistent permission errors with guidance to check access.

How do I stop the monitor?

Interrupt the command (Ctrl+C) to cancel monitoring; the monitor also exits automatically when the pipeline/job reaches a terminal state.