When things go wrong

The failures you will actually meet, what each one means, and what to do. Every one of these has happened on DoneMark's own record.

The release was refused: the branch does not merge

The work is accepted and its seal stands. What failed is only the merge: another attempt reached the default branch first, and this branch no longer applies to it cleanly.

Pressing Release again will not help. A release merges the branch the attempt was judged on, and that branch is exactly the one that no longer merges, so it is refused for the same reason every time.

The requirement page says the work is judged and not on the default branch, and offers Send it round again. That rebuilds the accepted work on today's default branch. Nothing is re-judged and the seal keeps its number. If the rebuild comes back green and merges cleanly, DoneMark releases it itself.

Two attempts that touched the same file will do this to each other, and the one that lands second is the one that has to go round. It is ordinary, not a fault.

"An attempt is holding the ground", or "a release is holding the ground"

Nothing is wrong. A release merges a branch into your default branch, and an attempt in flight has already rebased onto that branch and is building against it — merged underneath, the ground it stands on moves and its evidence would describe a base that was never a state of your project. So the two never overlap. Whichever is refused says how many are in flight and that pressing again once they finish goes through unchanged. Nothing is lost by waiting and nothing about the record changes in the meantime.

A refusal in DoneMark always leads with what you can do and when. If you meet one that only explains itself, that is a defect in the words, not in your project.

The agent's account has run out

An attempt that ends within seconds having spent nothing, with the agent's own words about a limit, is not your code failing — the account that runs the agent has no allowance left until the time it names. DoneMark records that as work that never started rather than as a failed attempt, so it never becomes the attempt a door opens on, and it holds the queue until the allowance returns.

The attempt ended with nothing

What you see. The run is failed, with no branch and no commit, and a sentence saying what the tool said as it ended — including its last words.

What it usually is. The agent's account hit a limit, or the process died. DoneMark writes down whatever the tool said about its own ending rather than inventing a reason, because a usage limit, a refusal and a cut connection otherwise read the same.

What to do. The Home lists today's attempts that ended this way under Ended with nothing, each with why — stopped at its time cap, its runner went silent, its key was refused, its account ran out of quota — and the one thing to do: Test the key, Send it again, or, when it has stopped at the time cap twice, Split it, or give it more time. Nothing is lost, because nothing was made.

An attempt would not merge with the default branch

What you see. In what waits for you, a stuck row: would not merge with main, and on the run page the files that clashed.

What it means. While the attempt worked, the default branch moved and changed the same lines. The runner tried to bring the attempt up to date and git refused. See the conflict names the files; the attempt goes back in the queue to be built again on today's default branch.

"CI left as it was"

What you see. On the ask's page: CI left as it was. The agent changed constat-ci.yml…

What it means. The agent changed one of your CI workflows, the files under .github/workflows/. An agent never changes the CI: the CI checks its work, so changing it is a person's call. GitHub also refuses the whole push when an agent's token touches one of those files. So before pushing, the runner put those files back as they were. The rest of the work was pushed and is judged as usual.

What to do. If the ask really needs that CI change, make it yourself on the default branch, then send the ask again. Otherwise, nothing: the ask goes on as built.

The attempt was halted

What you see. halted, with the reason: a spending cap, a time cap, you stopping it, or the runner never reported back.

Caps. If it finished and then crossed the cap, the record says so — its last commit and its report were already in place, and it is judgeable.

The runner never reported back means the builder died silently on the machine. DoneMark waited past the cap, heard nothing, and recorded it rather than leaving it running for ever.

What to do. If the requirement was too large for its envelope, split it. That is more often the cause than a slow machine.

Every criterion is green and the run is red

What it means. Something failed that no criterion claims — often a check in another part of the suite that your change broke, or a check somebody left broken earlier.

Where to look. The beyond the criteria section names it with its error line.

What to do. If it is this attempt's doing, refuse and say which check. If it belongs to older work, say that in your reason so the next attempt does not go chasing it.

A check timed out instead of failing

What you see. A check that ran for its whole limit and then stopped, with no assertion.

What it means. A screen that never rendered, an app that never answered, or a check that is genuinely just slow. A timeout does not distinguish them, which is why it is worth fixing rather than re-running.

What to do. Treat it as the machine's until shown otherwise, and press the checks again. Twice at the same commit is the code's.

CI could not be read at all

What you see. The project's health line carries the reason, in the words the other side gave.

Common causes. The witness is not installed on that repository. Its permissions changed and have not been accepted. Your CI is blocked by billing. Each of those says which it is.

"Sending work to agents is paused"

What you see. A band at the top of every screen, and the plan's question where Dispatch or Send it off used to be.

What it means. The plan has paused new work for agents: the first sign-off needs a card, the five free sign-offs are used, a payment failed 14 days ago, or the plan ended. A Builder plan also stops a fourth app in the same month.

What to do. An admin presses the band's button: add a card, choose a plan, update the card, or move to Studio. Everything already built can still be judged and signed off meanwhile, and the queue starts again by itself once the plan allows.

An attempt is queued and never starts

What it means. Nothing is listening. Either the project asks for a runner label no registered runner carries, or the repository has no runner workflow at all.

What to do. Check the project's where attempts run setting against the runners registered on that repository. The project's page says Lane 2: work waiting, no runner when a lane has work and nothing to take it.

Or it is held on purpose. Dispatch waits until the agent's key has passed a test (Waits for the key's test — Open the setup →). The queue also stops at its walls — too many verdicts waiting on a person, or the day's spending ceiling reached — and the project's page says Held at which one.

This copy talks to the live database

What you see. A red box on the run page, over the running copy.

What it means. The preview your host built for this attempt uses the same database as your live app — DoneMark compared a fingerprint of each, never an address or a password. Anything you try in that copy changes real data.

What to do. Give your host's previews a staging database of their own, then look again.

A release merged but is not live

What you see. The release stays at merged, not live.

What it means. DoneMark watches the address you gave for the application answering at that commit. Live is observed, never assumed, so this is telling you something real: your deploy has not finished, or it did not deploy that commit.

The agent says it did something CI did not see

What you see. A claim beside evidence that disagrees with it.

What it means. Exactly what it looks like. The claim stays on the record in the agent's words, and the evidence stays beside it. That is not an error state; it is the product working.