Troubleshooting

My job failed — what do I do?

Common reasons jobs fail and how to diagnose them from the job detail view.

Updated March 3, 2026

Jobs can fail for several reasons. Start by opening the job detail view in the Zapat dashboard — it shows an error code and the last agent message, which usually explains what went wrong.

TIMEOUT — Job took too long

The job exceeded its configured timeout (default 30 minutes for implementation). This usually happens with very large or complex issues. Try breaking the issue into smaller, more focused tasks, or increasing the timeout in Configuration > timeoutImplement.

API_ERROR — AI model failure

The AI model returned an error. This is usually transient. Wait a few minutes and retry the job by removing and re-adding the trigger label.

RATE_LIMITED — API rate limit hit

The AI provider's rate limit was hit. The job is automatically deferred and retried after 60 minutes (configurable). If this happens frequently, contact support — we can adjust retry behavior for your account.

GIT_CLONE_FAILED — Repository access issue

Zapat could not clone the repository. This usually means the GitHub App installation lost access to the repo. Reinstall the GitHub App or go to GitHub > Settings > Installed GitHub Apps > Zapat and verify the repo is still selected.

NO_OUTPUT — Agent produced no result

The agent ran but did not produce any code changes or PR. This typically happens when the issue is too vague, too broad, or the agent could not determine what to implement. Add more detail to the issue description — specific acceptance criteria, example inputs/outputs, or file paths to change — and retry.

BUDGET_EXCEEDED — Cost safety limit hit

The job exceeded the $12 per-job cost safety cap. This is a hard safeguard against runaway agent loops on extremely large codebases or ambiguous tasks. The issue is likely too broad or too large for a single job. Break it into smaller, more focused sub-issues and retry.

Tip

To retry any failed job: go to the GitHub issue, remove the trigger label, then add it back. This creates a fresh job with the current issue description.

Writing better issues to prevent failures

  • Be specific: "The login button does not work" → "Clicking the login button with empty email field does not show a validation error — it should show 'Email is required'."
  • Include file paths when you know which files need to change.
  • Include acceptance criteria: "The fix is complete when the unit test passes."
  • Keep scope tight — one issue should describe one change.
  • For bugs: include steps to reproduce, expected behavior, and actual behavior.

Was this article helpful?