Monitor runs

Find your run

Select the repository’s GitHub account in the dashboard, then open 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.

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 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.

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. Host diagnostics describe runner preparation and connection problems; they are separate from your test logs.

Actions billing estimates

The 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.