tracer-cloud--opensre/docs/integrations/github-actions.mdx

---
title: GitHub Actions
---

# GitHub Actions

OpenSRE’s GitHub Actions integration helps you trace incidents back to the workflow run that caused them.
It is designed for situations where a failed deploy, a flaky test, or a broken secret rotation explains a production problem.

## What it provides

- Recent workflow runs for a repository, including status and trigger
- Job and step summaries for a workflow run
- Failed job step log output
- Currently active workflow runs

## Configuration

This integration uses the same GitHub MCP credentials as the existing GitHub setup when available.

### Required

- `GITHUB_MCP_AUTH_TOKEN` (or a GitHub token supplied via the GitHub MCP integration)

### Optional

- `GITHUB_MCP_URL` to point at a custom MCP endpoint (defaults to `https://api.githubcopilot.com/mcp/`)
- `GITHUB_MCP_MODE`, `GITHUB_MCP_COMMAND`, `GITHUB_MCP_ARGS` for stdio-based MCP setups

If no token is configured, GitHub Actions tools will report that the GitHub integration is unavailable.

## Available tools

### `list_github_actions_workflow_runs`
List recent workflow runs for a repository.

Example:

```json
{
  "owner": "Tracer-Cloud",
  "repo": "opensre",
  "per_page": 10
}
```

### `list_github_actions_active_runs`
List queued and in-progress runs.

Example:

```json
{
  "owner": "Tracer-Cloud",
  "repo": "opensre"
}
```

### `list_github_actions_run_jobs`
List jobs and step outcomes for a run.

Example:

```json
{
  "owner": "Tracer-Cloud",
  "repo": "opensre",
  "run_id": 123456789
}
```

### `get_github_actions_step_log`
Fetch the log output for a failed job step.

Example:

```json
{
  "owner": "Tracer-Cloud",
  "repo": "opensre",
  "run_id": 123456789,
  "job_id": 987654321,
  "step_name": "Deploy"
}
```

## Investigation workflow

1. Find the workflow run that happened right before the incident.
2. Open the job list and identify the failed job or step.
3. Pull the failed step log and look for the exact deployment/test error.
4. Use the run metadata to correlate the failure with commits, pull requests, or a secret/config change.

## Example RCA usage

A failed deployment workflow often shows up as:

- a run with `conclusion: failure`
- a job named `deploy`, `release`, or `rollout`
- a step such as `Deploy`, `Apply manifests`, or `Run migrations`

That context is usually enough to connect the incident to a recent workflow change.