Deployment Failure Patterns
Review recurring deployment failures grouped by category, with occurrence counts, affected deployments, and suggested fixes.
Devpilot analyses the diagnosis of every failed deployment and groups recurring failures into failure patterns. A pattern captures a specific signature of failure on an app so that the second and subsequent occurrences can be recognised instantly, linked back to the deployments they affected, and (when available) paired with a suggested permanent fix.
Failure patterns are tracked per app, not per workspace. Open an app to see its patterns.
How patterns are built
When a deployment fails, Devpilot produces a diagnosis. The diagnosis is assigned one of five categories, and a signature is computed from the failure details. If a later failure on the same app produces the same signature, it is attached to the existing pattern instead of creating a new one. The pattern's occurrence count and last-occurred timestamp advance with each new hit.
A pattern becomes recurring once it has three or more occurrences.
Categories
Every failure pattern is classified into exactly one of these categories.
Dependency failure — a package manager step failed to install or resolve a dependency (for example an npm install, composer install, pip install, or lockfile-resolution error).
Git failure — the deployment could not clone, fetch, or check out the repository at the requested reference (for example authentication failure, missing branch, or a shallow-clone problem).
Database connection — the deployment failed to reach or authenticate with the application's database during a build or post-deploy step.
Runtime error — the build or post-deploy command itself threw an unhandled error at runtime (for example an exception in a migration script or a failing smoke test).
Configuration error — a required environment variable, config value, or file was missing or invalid.
What a pattern records
For each failure pattern Devpilot stores:
| Field | Description |
|---|---|
| Category | One of the five categories above. |
| Pattern signature | A stable hash that uniquely identifies this failure. |
| Occurrence count | How many failed deployments matched this pattern. |
| First occurred at | Timestamp of the first matching failure. |
| Last occurred at | Timestamp of the most recent matching failure. |
| Deployment IDs | The list of deployments that hit this pattern, linked back to the deployment page. |
| Suggested permanent fix | A fix proposal, when Devpilot has enough signal to suggest one. |
| Is resolved | Whether a team member has marked the pattern resolved. |
| Resolved at | The resolution timestamp. |
Viewing patterns on an app
Open an app, then open its Failure Patterns view. By default the list shows unresolved patterns with three or more occurrences (the ones worth your attention), sorted by occurrence count descending and then by last-occurred time.
Click any pattern to see:
- The category, occurrence count, and first/last occurrence.
- The list of affected deployments, each linking to its own diagnosis page.
- The suggested permanent fix when available.
Resolving a pattern
When you have shipped a fix, mark the pattern as resolved. This:
- Marks the pattern Resolved and records the resolution time.
- Removes the pattern from the default (unresolved) list.
- Leaves the history intact — you can still open the pattern to see the deployments that hit it.
If a future deployment triggers the same signature again, Devpilot re-opens the pattern so you know the fix did not hold.
Relationship to deployment diagnosis
Each failed deployment has its own diagnosis page. The diagnosis is where you read the full build output, inspect the failing step, and see Devpilot's initial analysis. Failure patterns sit above individual diagnoses — they tell you which diagnoses are actually the same problem happening repeatedly.
Failure patterns only cover deployment failures. Runtime errors inside your application once it is running are not tracked here — forward application errors to a dedicated error-tracking service (Sentry, Rollbar, Bugsnag, etc.) if you need that visibility.
Best practices
- Triage recurring patterns first: a dependency failure that has hit 15 deployments is almost certainly a lockfile or registry problem worth fixing permanently.
- Follow the deployment IDs: the linked deployments reveal when the pattern started and what changed around that time.
- Resolve explicitly: marking a pattern resolved is how you claim the fix; if the pattern re-opens later you will know the fix was incomplete.
- Read the suggested fix: when Devpilot has proposed a permanent fix, apply or rebut it — the proposal is based on the signatures and diagnoses of the repeat failures.
Related pages
- Activity logs — see who triggered each deployment and what changed around the failures.
- Logs — hook output from the failing runs lives in the deployment hook log.