Failures
How Prodgator assigns a category to each failed pipeline run and counts repeat failures.
Availability
When a run fails, Prodgator gives it a failure category so you can see why runs break without reading every log. The category shows on the run and feeds the Failures page.
How a run is classified
Classification runs once, when a run first changes to failed.
- Business and Enterprise: Prodgator fetches the failed jobs' logs from the provider and asks an AI model to pick a category and quote the one or two log lines that explain the failure. If the model call fails, Prodgator falls back to pattern matching on the log. If no log can be fetched, the category is . When an AI failure explanation is written for the run, its category replaces .
- Team: Prodgator fetches the failed jobs' logs and matches known patterns against them. The log's error lines become the run's excerpt.
- Free: Prodgator matches known patterns against the commit message. Most runs end up as .
Categories
| Category | Meaning | Typical signs |
|---|---|---|
| A test that passes and fails without code changes | Tests that pass on retry, or logs that mention flaky tests or failed retries | |
| Package installation, resolution or compatibility problems | , yarn errors, unresolved dependencies, missing modules | |
| Compilation or build tool failures caused by code changes | Compiler or syntax errors, , "build failed" | |
| Infrastructure timeouts not caused by the code | Timeouts, , "context deadline exceeded" | |
| A real test failure caused by a code change | Failing assertions, "Test failed", | |
| Access control or authentication failures during the run | "permission denied", , | |
| Nothing matched, or no log was available |
Passed on retry
When a run passes, Prodgator looks for earlier failed runs of the same workflow, repository and branch on the same commit. The code did not change between them, so each of those failures is marked Passed on retry and its category becomes . If an AI failure explanation already named a category for the run, that category stays, and the run is still marked Passed on retry. If an explanation is written later, its category replaces .
A re-run that keeps the same run (GitHub Actions and Bitbucket re-runs add an attempt to the run) does not leave a failed run behind: the run passed. Pipelines shows Passed on retry on it, with the attempt that passed.
Recurrence
With each classification Prodgator counts how many failed runs of the same workflow, in the same repository, with the same category, happened in the last 7 days. A high count on points at a test to fix.
Failures page
The Failures page lists every failed run your plan keeps, newest first, in the same table as Pipelines: workflow and run number, cause, repository, branch, commit, actor, trigger, when it failed, duration and jobs. Above the table, Causes counts the failures per category; click a cause to show only those failures. Causes over time charts the failures per day by category over the selected time range (per week when the range is longer than 90 days), in your time zone. Click a category in the chart to filter the list like Causes, or switch to Show as table to read the numbers. A failure marked Passed on retry links to the run that passed. Filter by search text, repository, branch, workflow, trigger, actor, organization, platform and time range; filters stay in the page address, so you can share a filtered view. The refresh button in the top bar reloads the list.
Click a row to expand it in place. The expanded row shows:
- What failed: each failed job of the run's latest attempt, with a link to the job, its failed steps (GitHub Actions) and the end of its log around the last error. Prodgator reads the log from the provider when you expand the row and removes secrets it recognizes. If the log can't be read, open the job in the provider.
- Status: whether the workflow still fails on that branch (the latest run of the same repository, workflow and branch), passes again, or passed when it ran again on the same commit (the failure may be flaky). When earlier runs failed too, it shows how many runs in a row failed and the commit where it started failing.
- Change: the commit and its message, the author, who started the run, the trigger (with the pull request when there is one) and the cause.
- Actions: re-run the failed jobs (needs the permission), open the run in Prodgator or in the provider, and create or link a Jira issue when Jira is connected.
- Why this run failed: the AI failure explanation, when AI features are on. Explain failure writes one (1 AI credit) if none exists yet.
The dashboard's failure patterns widget groups failures by workflow and category.
Notifications
On Business and Enterprise, Prodgator also rewrites a failed-run notification's message with added context from the run.
AI failure explanations
If your organization has turned on AI features, Prodgator can also write a short root-cause summary and a suggested fix for a failed run. See AI failure explanations.