Documentation

Tenant OwnerReviewerOperator

Product knowledge base, playbooks, and embedded guidance for every persona.

🔁 Retry Policy & Error Handling

CoffeeBreakAI includes an adaptive retry and error-handling system that helps automated tasks recover from transient issues while surfacing true problems for human review.

A Retry Policy defines:

  • When CoffeeBreak should retry a task
  • How many attempts it can make
  • How long it waits between attempts
  • Which failures are safe to retry
  • When the task must pause for human review

Retry policies keep automation stable, reduce noise, and protect your workflows from both transient errors and deeper structural problems.

🧩 Error Categories

CoffeeBreakAI categorizes errors into two groups:

Recoverable Errors

Short-lived or non-critical issues:

  • Network timeouts
  • Provider rate limits
  • Temporary service unavailability
  • Missing or incomplete context
  • Output truncated or partial
  • Other issues marked as retryable by agents or Retry Hints

Non-Recoverable Errors

Structural or logic-level failures:

  • Invalid configuration or credentials
  • Missing permissions
  • Broken business rules
  • Conflicting requirements
  • Critical logic errors

Recoverable errors may be retried automatically.
Non-recoverable errors typically stop execution and send the task to Failed or Review Required, depending on workspace rules.

🔁 When CoffeeBreak Retries Automatically

CoffeeBreakAI will retry a task when:

  • The failure appears transient or short-lived
  • There are remaining retry attempts
  • The agent marks the issue as recoverable
  • A Retry Hint is present (see Retry Hints)
  • The system’s confidence is high enough that retrying is useful

CoffeeBreak may adjust the task using the hint or safe defaults before trying again.

For example behavior, see
👉 Retry Behavior

🛑 When CoffeeBreak Stops Retrying

CoffeeBreak will not retry when:

  • The maximum retry count is reached
  • The error is non-recoverable
  • The issue is ambiguous or critical
  • A human reviewer has already intervened
  • The system is not confident a retry will help
  • The task requires a human decision

In these cases, the task moves into Paused for Review and awaits input.

⚙ Workspace Configuration

Admins can tailor retry behavior at the workspace level:

Max Retry Attempts

How many automated retries are allowed.

Backoff Strategy

Immediate retries or exponential backoff.

Retry Severity Rules

Define which errors trigger automatic retry.

Confidence Requirements

Low-confidence retries may require human approval.

Task-Type Overrides

Some task types may allow more—or fewer—retries.

📊 Review Integration

Retries and human review work together:

  • Repeated failures can trigger review automatically
  • Reviewers can inspect error context, retry history, and hints
  • Reviewers can approve changes or request a manual retry

For details, see
👉 Human Review & Reviewer Scheduling

🔍 Viewing Retry History

Retry attempts appear in:

  • The Task Details timeline
  • The Retry section of the execution history
  • Reviewer comments (e.g., on pull requests)
  • Workspace logs

Each retry shows:

  • Result of the attempt
  • Retry Hint (if any)
  • Reason for retry
  • Applied backoff delay
  • Remaining attempts