GHA Insight

/gha-insight

Failure causesFlaky jobsRunner queueDeploys & DORARunner-minutesFix list

One answer to "is our CI/CD healthy, and what do we fix first?" across every repository in scope. Every non-successful job gets exactly one cause, found by reading its steps and its raw log, so infrastructure problems (a runner that disappeared mid-job) are separated from application and config failures. Needs the ghaInsight feature, which is off by default: turn it on in Settings → My features (standalone) or grant it in Settings → Access by group (organization mode).

Tab	What it answers
Overview	A verdict, the headline rates against the previous window, top causes, weekly trend and the first fixes
Failures	Every non-successful job by cause, recurring error groups with redacted log excerpts, and a run drill-down
Flaky & retries	Jobs that failed and then passed on a retry of the same commit, kept apart from runner-loss retries
Runners & queue	How long jobs wait for a runner, the slowest pickups, runner-lost jobs by repository, and usage by runner label
Repos & workflows	Repositories ranked by failure rate (not count), runner-minutes, runner loss or flakiness
Deployments & DORA	Production deploys, failed deploys with time to restore, lead time, change failure rate
Compute	Runner-minutes by repository, workflow and job, measured from job start and end times
Recommendations	Rule-based fixes ranked by how many failures each would remove, with the evidence
Settings	Scope, what counts as a build, a deploy and production, cause detection, redaction and thresholds

The page reads from GitDash's own copy of your GitHub Actions data, never from GitHub on a page view. A daily sync (/api/cron/sync-gha, 05:17 UTC on Vercel) keeps it current, and Sync now in the header runs one at any time: admins in organization mode, the signed-in user in standalone. An organization is synced daily once someone ran Sync now or saved its rules (with GITDASH_ALLOWED_ORGS set, only those organizations). In standalone mode any member of an organization can do that, and the daily sync then uses the service GITHUB_TOKEN for it; set GITDASH_ALLOWED_ORGS to keep it to organizations you choose. Self-hosted installs call the cron route from their own scheduler with Authorization: Bearer $CRON_SECRET, or sync only with Sync now. The header says when the data was last synced. Windows are 7, 14 and 30 days, each compared with the period before it; you see only repositories your own GitHub token can list. Needs DATABASE_URL.

Sync	What happens
First sync (backfill)	Lists 60 days of runs for every repository, then reads jobs and logs newest day first, back 30 days, so the 7-day window is complete first. A large organization takes several runs of up to 250 seconds and a few hours of quota; Sync now keeps going until it finishes or pauses.
Daily sync	Re-lists the last three days of runs, so re-runs and late finishes are picked up, and reads jobs and logs only for new or changed runs. A few hundred to about a thousand calls.
Quota	All syncs with one token together use at most 60% of its hourly limit: a sync pauses when 40% is left and says when it resumes. The daily sync uses the service GITHUB_TOKEN; Sync now uses yours.
Partial data	Until the backfill reaches a window's start, or while some job reads keep failing, Data quality marks the window partial and says how far jobs and logs go back. A repository whose run list was capped or whose sync failed is left out of the figures, with a note.
Rule changes	Thresholds, costs, build matchers and title or branch production rules apply on the next page view. Deploy workflows and the production environment apply after the next sync, which re-reads deployments and merge times over the 60 days kept. Runner-loss signatures and redaction apply to logs read after the change.

Only logs of non-successful jobs are read, and only a short excerpt around the error is kept. It is redacted before it is stored: GitHub already masks registered secrets, and the redaction patterns in Settings catch the rest (keys, tokens, emails, AWS account IDs, internal hosts). Excerpts and jobs are deleted after 30 days, runs after 60. A new redaction pattern is also applied to stored excerpts when they are shown.

GitHub can't see node or spot interruptions, and has no cost data for self-hosted runners. Runner loss is detected from GitHub's own log message; enter a per-minute rate per runner label on the Compute tab to estimate cost.

Tab

What it answers

Overview

A verdict, the headline rates against the previous window, top causes, weekly trend and the first fixes

Failures

Every non-successful job by cause, recurring error groups with redacted log excerpts, and a run drill-down

Flaky & retries

Jobs that failed and then passed on a retry of the same commit, kept apart from runner-loss retries

Runners & queue

How long jobs wait for a runner, the slowest pickups, runner-lost jobs by repository, and usage by runner label

Repos & workflows

Repositories ranked by failure rate (not count), runner-minutes, runner loss or flakiness

Deployments & DORA

Production deploys, failed deploys with time to restore, lead time, change failure rate

Compute

Runner-minutes by repository, workflow and job, measured from job start and end times

Recommendations

Rule-based fixes ranked by how many failures each would remove, with the evidence

Settings

Scope, what counts as a build, a deploy and production, cause detection, redaction and thresholds

Sync

What happens

First sync (backfill)

Lists 60 days of runs for every repository, then reads jobs and logs newest day first, back 30 days, so the 7-day window is complete first. A large organization takes several runs of up to 250 seconds and a few hours of quota; Sync now keeps going until it finishes or pauses.

Daily sync

Re-lists the last three days of runs, so re-runs and late finishes are picked up, and reads jobs and logs only for new or changed runs. A few hundred to about a thousand calls.

Quota

All syncs with one token together use at most 60% of its hourly limit: a sync pauses when 40% is left and says when it resumes. The daily sync uses the service GITHUB_TOKEN; Sync now uses yours.

Partial data

Until the backfill reaches a window's start, or while some job reads keep failing, Data quality marks the window partial and says how far jobs and logs go back. A repository whose run list was capped or whose sync failed is left out of the figures, with a note.

Rule changes

Thresholds, costs, build matchers and title or branch production rules apply on the next page view. Deploy workflows and the production environment apply after the next sync, which re-reads deployments and merge times over the 60 days kept. Runner-loss signatures and redaction apply to logs read after the change.