How often does Fleet check GitHub for CI and PR changes?

The brain daemon polls GitHub on a 5-minute heartbeat through the sourcecontrol provider. State is near-real-time, not instant — a CI failure surfaces on the next heartbeat after it occurs.

Can Fleet monitor my production deployments?

No. Fleet monitors pull requests, reviews, CI checks, issues, and merges on GitHub. It does not watch deployments, infrastructure, or production runtime — that signal lives in your deployment and observability tooling, not in Fleet.

What CI events does Fleet emit?

The two real CI events are `ci_pass` and `ci_fail`. You can subscribe an agent to `ci_fail` to pull the PR author back in to fix a broken branch, exactly like a `pr_changes_requested` event.

Do I need GitHub webhooks for this to work?

No. Fleet polls GitHub through the `gh` CLI on the brain's 5-minute heartbeat. There is no webhook infrastructure to set up — the trade-off is a small polling delay rather than instant push notifications.

How to Monitor CI and Pull Requests with AI Agents

Name: Fleet
Author: Fleet

When a fleet of AI coding agents is opening pull requests, requesting reviews, and merging changes, the hardest thing to keep track of is the state of GitHub itself. A PR sits unreviewed, a CI check fails on a branch nobody is watching, an issue gets reassigned — and no human is in the loop to notice. Polling GitHub by hand defeats the purpose of automating the work in the first place.

Fleet's brain daemon solves this with a background heartbeat. Every five minutes it polls GitHub through the sourcecontrol provider abstraction — pull requests, reviews, CI checks, issues, and merges — and turns what it sees into actionable insights you can read with one command. This guide covers what the brain watches, how to read its output, and where the honest boundary of that monitoring lies: Fleet watches your code-review and CI pipeline, not your deployments or production runtime.

Before you start

Fleet installed and initialized in your repository (`fleet init`)
GitHub CLI (`gh`) authenticated with read access to the repository
At least one agent defined in `.fleet/config.yaml` so there is activity to monitor
A repository where pull requests and CI checks actually run

Understand what the brain heartbeat polls

The brain daemon is Fleet's event-driven monitor. On a 5-minute heartbeat it polls GitHub through the sourcecontrol provider (a thin abstraction over the gh CLI) and pulls in pull requests, review state, CI check results, issues by assignee, and merges. It correlates that GitHub state with each agent's activity. Be clear about the boundary: the brain monitors your code-review and CI pipeline — PRs, reviews, checks, issues, merges. It does not monitor deployments, infrastructure, or production runtime. If a check passes in CI and the PR merges, the brain knows; what happens after the merge in your deploy system is outside Fleet's view.

# The brain heartbeat polls GitHub every 5 minutes for:
#   - open pull requests + review decisions
#   - CI check results per PR (pass / fail)
#   - issues assigned to your agents
#   - merges
# It does NOT watch deployments or production runtime.

Start the brain daemon

Run fleet brain start to launch the daemon. It opens a unix socket at ~/.fleet/brain.sock, begins its 5-minute heartbeat, and runs per-agent evaluation and risk assessment alongside the GitHub polling. The daemon runs in the background; you do not need to keep a terminal attached.

fleet brain start

# Confirm the daemon is up:
fleet status

Read the insights the brain surfaces

The brain converts what it observes into actionable thoughts. Use fleet brain insights to see them: stalled PRs waiting on review, agents that have gone silent, CI failures correlated with a specific agent's work. This is the single command you check to understand the health of the review-and-merge pipeline without opening GitHub.

fleet brain insights

Trace CI and review events in the decision log

CI and review activity flows through Fabric as structured events. The real CI events are ci_pass and ci_fail; review events include pr_created, pr_needs_review, pr_approved, pr_changes_requested, and pr_reviewed. Use fleet log to see the chronological trail and filter to the events you care about. This is where you confirm whether a check passed before a merge happened.

# See every CI and review event in order:
fleet log --type decision --since 24h

# Filter to one agent's pipeline activity:
fleet log --agent backend-dev --since 24h

Wire CI failures back into the chain

Monitoring is only useful if something acts on it. A ci_fail event can re-engage the developer that owns the PR: have the developer agent subscribe to it so a failed check pulls the author back in to fix the branch, the same way pr_changes_requested does. The brain surfaces the failure; the reactive chain routes the rework.

agents:
  - name: backend-dev
    role: backend-developer
    department: engineering
    reports_to: tech-lead
    subscribes_to:
      - ticket_ready
      - pr_changes_requested
      - ci_fail

Check the brain socket and PID when monitoring stops

If insights stop updating, confirm the daemon is alive. The brain writes a PID file to ~/.fleet/brain.pid and listens on ~/.fleet/brain.sock. If the daemon died, restart it. The heartbeat is the only thing polling GitHub — without it, no new insights appear.

# Verify the daemon, then restart if needed:
fleet status
fleet brain start

Common pitfalls

The heartbeat polls every 5 minutes. CI and review state is near-real-time, not instant. A check that fails one second after a poll will not surface until the next cycle. This is by design — polling avoids GitHub webhook infrastructure.
The brain monitors PRs, CI checks, issues, and merges only. It does not watch deployments, staging environments, or production runtime. Do not rely on Fleet to tell you a deploy failed — that signal lives in your deployment system, not in the brain.
If the brain daemon is not running, there is no GitHub polling at all. `fleet brain insights` will show stale or empty output. Always confirm the daemon is up before trusting an empty insight list as 'all clear'.
Only the real CI events `ci_pass` and `ci_fail` are emitted for checks. Do not build subscriptions against invented names like `ci_failed` or `deploy_approved` — they will silently never match.
GitHub API rate limits apply to the polling daemon. On a busy repository with many open PRs, the per-heartbeat poll consumes API budget; running the brain alongside the watcher's own 2-minute label polling compounds that usage.

When Fleet is the right tool

Fleet's brain monitoring earns its place when agents are opening and merging PRs faster than a human can track, especially during unattended overnight runs. It gives you one command — fleet brain insights — to know whether the review-and-merge pipeline is flowing or stalled. It is honestly not a deployment or uptime monitor: if your real concern is production health, a runtime observability tool is the right choice and Fleet is the wrong one. Use Fleet for the GitHub side of the pipeline — PRs, reviews, CI checks, issues, and merges — and keep production monitoring where it belongs.