What Qoffee does not do

Qoffee reads job statuses, sends messages, and edits tags on jobs you told it to watch. That is the whole list. In particular it does not do any of this.

• It does not run your jobs. You submit them exactly as you did before.
• It does not read your results. The notification carries a status, a backend name, and an error message when there is one. It never touches the result data.
• It does not resubmit failures. It tells you which jobs failed. Deciding what to do about that is yours.
• It does not touch untagged jobs. Discovery is an exact match on the tag qoffee. A job without it is invisible to Qoffee.
• It does not message you when nothing has changed. Silence is the normal state.

Where it is limited

None of them are bugs, and all four are visible in the source.

The schedule slips

The workflow asks for a run every 15 minutes. GitHub delays scheduled runs when its infrastructure is busy, and 30 to 40 minute gaps are ordinary depending on the time of day. The cron expression is a floor, not a promise, and the workflow file says so in a comment.

For queues measured in hours this does not matter. If it matters to you, drive the workflow from a Cloudflare Worker, which fires on its own schedule and costs nothing.

A failure can sit in your messages for a while

Failures are held until nothing else in the batch is moving, so that the final message of a batch is failures only. If you submit work continuously, the batch may never go quiet, and the failure stays in every message until it does.

Set FAILURE_AUTOCLEAR_HOURS to a number of hours if you work that way. It is off by default because for most people the batch does go quiet, usually the same day.

Five tags per job, and Qoffee wants two

IBM allows five tags on a job and caps each at 24 characters. Qoffee uses qoffee for discovery and a second tag for state, so a job carrying five of your own tags leaves it nowhere to write.

When that happens the run exits with code 4, goes red in the Actions tab, and names the job in the log. It does not retry silently, because there is no database in which to record that it gave up, and retrying forever would show up as endless duplicate notifications on a green run.

Remove one tag from that job, or remove qoffee from it, and the next run continues normally.

Two more things that surprise people

An empty commit appears in your fork every 45 days. GitHub disables scheduled workflows on repositories with no commit activity for 60 days, silently, and that also kills manual dispatch. The workflow pushes an empty commit labelled chore: keepalive to reset that clock. If you see one in your history, that is what it is.

The tracking tag cannot be renamed. Qoffee writes qoffee@F:1755835200 to pin a reported failure, which needs 13 characters on top of the tag name, and IBM caps tags at 24. A longer tag name cannot be encoded, so the failure state would fail to persist and the job would be re-reported forever. Use name: labels to tell your jobs apart instead.

Everything above is checkable. The schedule comment is in .github/workflows/watch.yml, the delivery ordering is in qoffee/core/engine.py, the failure holding is in qoffee/core/policy.py, and the tag limits are in qoffee/settings.py.