# Monitor runs

Follow jobs across providers, inspect routing decisions, and open their logs in GitHub.

Runs brings your jobs’ execution history together across providers. Use it to see where a
job ran, understand a fallback decision, or compare the results of a provider experiment.

## Find your run

Select the repository’s GitHub account in the dashboard, then open [Runs](https://mirageci.com/runs). Find the
workflow and expand it to see its jobs. If it is missing, check the selected account and the
App’s repository access in Settings.

Mirage receives workflow activity after the GitHub App is connected. Connect all
repositories you want to monitor; enabling Mirage execution is a separate choice.

When a repository is connected, Mirage also imports its previous six months of runs from
GitHub in the background, so Runs, Repos and Billing show history from before you installed
it. A busy repository can take a few hours: the import pauses whenever GitHub’s API limit
runs low so your CI keeps priority. GitHub keeps step details only for recent runs, so older
jobs show their result and timing without steps.

## Read the result

Open a job to see its result, runner provider, available timing information, and machine
assignment. The route reason explains why Mirage used your machine or a fallback. Expand the
job’s steps to see progress and step timings.

Hover or focus **Failed runs (last 24h)** for a breakdown of recorded causes: failed CI
steps, runner or infrastructure errors, memory or disk limits, mixed causes, and unknown
causes. Each run counts once, using its latest attempt. Failed steps do not by themselves
prove a code defect; follow the GitHub logs to investigate. Unknown means Mirage lacks
enough runner or step evidence to classify the failure.

| What you see | What it means |
| --- | --- |
| GitHub on attempt 1 | The job used a GitHub-hosted runner as its normal route. |
| Local infrastructure on attempt 1 | The job was routed to your connected machines. |
| Cloudflare | The job ran on the selected shared or BYO Cloudflare account. |
| GitHub on a later attempt | The job used the hosted label after fallback or a manual rerun. |
| A failed build or test | Open the step logs in GitHub to diagnose the application failure. |
| Queued or unavailable | Check the route reason, repository setup, and machine readiness. |

Attempt numbers belong to GitHub’s workflow run. Fallback keeps the same run ID and adds a
new attempt.

For an onboarded job, open its provider comparison to see each experiment’s result and
available capacity-wait, startup, and execution timings. Follow
[Compare CI providers](https://mirageci.com/docs/ci-providers.md) to evaluate a different default route.

## Resource use

A job that ran on your machines or on Cloudflare shows its memory, CPU, disk and network use
over the job, with its steps marked. Memory shows its peak and CPU its percentiles. Disk
shows read and write throughput with the totals, and, where the runner measures the job’s
own disk, the most of that disk the job used at once against its size, as in “6.3 GB peak of
6.4 GB”. The runner image sits on the same disk, as does a swap file on a Mac, so the peak
includes them.

Linux jobs on a Mac and Cloudflare jobs show the disk peak. A Linux host’s Docker runtime
measures the host’s whole disk, a Proxmox VM’s disk comes from its template rather than the
budget, and a macOS VM reports a system volume the job doesn’t write to, so those jobs show
throughput only.

When a Linux job on a Mac fails with its disk full, Runs marks it **Out of disk**, its Disk
peak turns amber, and the open job says what Mirage did about it. See
[My job ran out of disk](https://mirageci.com/docs/troubleshooting.md#job-ran-out-of-disk).

## Logs and artifacts

Follow the run or job’s GitHub link for full step output and downloadable artifacts. GitHub
remains the source of truth for checks and CI results. Mirage keeps routing, status, and
timing information so you can understand execution without copying your full CI logs into
another service.

For host setup failures, use the machine’s status and [host
diagnostics](https://mirageci.com/docs/troubleshooting.md). Host diagnostics describe runner preparation and
connection problems; they are separate from your test logs.

## Actions billing estimates

The [Billing](https://mirageci.com/billing) page estimates monthly GitHub Actions usage for the selected account
using observed jobs. It includes repositories shared with the App even if they do not use
Mirage runners. History imports can still be in progress, so totals may not yet include
all earlier activity.

Treat this as an estimate of GitHub Actions spend, not an invoice or a Mirage service price.
Check GitHub for your actual charges and Cloudflare for usage billed to your own Cloudflare
account.

Queued jobs show why they are waiting beside their name: runner readiness, resource capacity, GitHub handoff, approval, runner startup or a Cloudflare container. Missing runner labels appear as an exception. Elapsed wait stays in the duration column. Aggregate stage counts and sampled timings are available with `mirage diagnostics lifecycle --account ACCOUNT`; machine startup timings remain under Reliability on the machine page.

Select a capacity explanation to view Machines, an unsupported-label explanation to review repository setup, or an approval explanation to open GitHub. If live updates disconnect or a refresh fails, a floating notice shows the last successful update and lets you retry while keeping the current runs visible.