# Github Actions Status

> View and monitor GitHub Actions workflow runs, statuses, and logs using the gh CLI. Lists workflows, inspects run details, follows logs, checks commit statuses, and triggers new runs.

- Skill: `paulpas/github-actions-status` (Agent Skill)
- Install (CLI): `npx skillmds@latest add paulpas/github-actions-status`
- Raw SKILL.md: https://api.skillmd.com/api/skills/paulpas/github-actions-status/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- License: MIT
- Author: paulpas (https://skillmd.com/u/paulpas)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/paulpas/github-actions-status

---






# GitHub Actions Status

View, monitor, and manage GitHub Actions workflows and their run statuses using the `gh` CLI.

## When to Use This Skill

- Checking the status of CI/CD pipeline runs
- Debugging failed workflow runs by viewing logs
- Monitoring a run until completion
- Listing all workflows and their recent activity
- Triggering a workflow run manually
- Checking commit-level check run statuses via the API

## Prerequisites

- **`gh` CLI must be installed and authenticated** with a GitHub account that has access to the target repository.
- Verify authentication: run `gh auth status` — if not logged in, run `gh auth login`.
- The `--repo <owner>/<repo>` flag is used on all commands to target a specific repository.

## Core Workflow

### Step 1: Identify the Repository

Determine the target repository in `owner/repo` format. If working in a local git repo, you can extract it with:

```bash
git remote get-url origin | sed -E 's|.*:(.+)/(.+)\.git|\1/\2|'
```

### Step 2: List All Workflows

See every workflow file and its last run status:

```bash
gh workflow list --repo <owner>/<repo>
```

This shows each workflow name, ID, state (active/disabled), and the time of its last run.

### Step 3: List Recent Workflow Runs

View the most recent runs across all workflows:

```bash
gh run list --repo <owner>/<repo> --limit 20
```

Use `--status` to filter by state (`pending`, `in_progress`, `completed`, `cancelled`, `failed`, `skipped`, `success`, `neutral`, `timed_out`, `action_required`):

```bash
gh run list --repo <owner>/<repo> --status failed --limit 10
gh run list --repo <owner>/<repo> --status in_progress --limit 10
```

### Step 4: Inspect a Specific Run

View detailed information about a single run:

```bash
gh run view <run-id> --repo <owner>/<repo>
```

This shows the workflow name, status, conclusion, duration, trigger, branch, commit message, and a summary of each job.

### Step 5: View Run Logs

For debugging a failed run, fetch the full logs:

```bash
gh run view <run-id> --repo <owner>/<repo> --log --job <job-id>
```

If no `--job` is specified, all job logs are shown. To list jobs within a run:

```bash
gh run view <run-id> --repo <owner>/<repo> --jobs
```

### Step 6: Monitor a Run in Real-Time

Watch a run's progress until it completes (useful for long-running pipelines):

```bash
gh run watch <run-id> --repo <owner>/<repo>
```

This polls the run status and prints updates. It exits with a non-zero code if the run fails.

### Step 7: Check Commit-Level Check Runs

Query check runs for a specific commit via the GitHub API:

```bash
gh api repos/<owner>/<repo>/commits/<sha>/check-runs
```

This returns check suites and individual check runs, including their conclusions and detailed output.

### Step 8: Trigger a Workflow Run

Manually trigger a workflow:

```bash
gh workflow run <workflow-name> --repo <owner>/<repo> --ref <branch-or-tag>
```

The `--ref` flag specifies which branch/tag to run against (defaults to the default branch).

## Reference

### All Commands

| Action | Command |
|
---

## Constraints

### MUST DO
- Implement all core functionality with explicit error handling and validation at every boundary
- Document the purpose and expected inputs/outputs of each public interface in docstrings or comments
- Use consistent naming conventions that clearly communicate intent — variable names should describe what they represent, not how they are used

### MUST NOT DO
- Do not implement features without considering edge cases, error states, and failure modes
- Avoid accepting unvalidated input at any API or interface boundary
- Never use magic numbers or hardcoded strings that obscure the purpose of configuration values