> Source: https://www.gitdash.info/docs/feat-gha-insight · GitDash v5.0.0

# GHA Insight

`/gha-insight`

Failure causes Flaky jobs Runner queue Deploys & DORA Runner-minutes Fix 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.