Failures on devboxes' side
Work on capacity that devboxes manages can fail for two kinds of reasons. Some come from the work itself: its tests fail, it runs out of memory, or it fills its disk. Others come from devboxes: the machine went away, stopped responding, or was reclaimed, maintenance drained it, devboxes couldn't prepare the workspace, or devboxes hit an internal error. The second kind isn't yours to fix, so devboxes retries that work by itself.
What devboxes retries
devboxes retries a work Run, and a Review's review, fix, and recheck Runs, when they fail because of a problem on its side. It waits 1 minute before the first retry, 4 minutes before the second, and 15 minutes before the third, and runs the retries away from the machines where the work failed. After the third retry, a problem on its side fails the work.
devboxes doesn't retry a failure that a retry wouldn't change. Running out of memory, exceeding the disk limit, and reaching the time limit after the start end the work right away. So does a cause that is the person's, such as the Organization's own configuration. A Run that still waits for room on managed capacity when its time to start runs out isn't retried either.
Where a retry continues
When the work fails before it starts, the same Run waits and starts again. While it waits, sessions.inspect shows it as queued with the queue reason retry.
A failure after the start ends that Run. The retry is a new Run in the same Session, with the same instruction, Blueprint, and inputs. It continues from the Session's last saved point, or from the Session's start when the Session hasn't saved a point yet, and the failed Run stays in the Session's history. When the failed Run hadn't saved its progress, the retry's agent learns that an earlier attempt failed before saving, and, in a Project with a repository, that the attempt may already have pushed work to the Session's branch or its pull requests.
A Review keeps its state and its fix budget across retries of its own Runs. When the pull request changed while the Review waited, or after the third retry, the Review stops and leaves the work to a person.
When devboxes can't start a retry, for example because the delegation of the Chat thread that started the work was revoked or the work's model account was removed, the work fails as it would after the third retry.
What you hear
devboxes' team gets an alert for every failure on devboxes' side, so a machine that fails work again and again stays visible. A Chat thread or an issue's conversation hears about retried work once, when the work's last attempt ends. When that attempt failed on devboxes' side too, devboxes says so.
What you pay
A managed Run that failed because of devboxes isn't charged right away. Its cost is parked until devboxes has looked at it, as How billing works explains. A retry is charged like any other Run, and is parked too when it also fails because of devboxes.