How Qoffee works

Qoffee has no database. There is no state file, no jobs.yaml, no spreadsheet, and no server holding a list of what you are watching. IBM's own job tags are the entire tracking mechanism, from discovery through to cleanup.

The whole loop

1. You submit a job carrying the tag qoffee.
2. A GitHub Action runs, on a schedule or because you pressed a button.
3. Qoffee asks IBM for every job tagged qoffee.
4. It compares each job's status against the status recorded in its second tag, and sends a message if anything differs.
5. After the message is confirmed delivered, finished jobs have their tags rewritten to qoffeed, which removes them from the next query.

Between runs, nothing anywhere remembers anything. The next run rebuilds its entire picture of the world from IBM's tags.

Why this matters to you

The no-database decision allows four useful things to fall out of it.

The repository can be public. There is nothing in it about you: no job IDs, no history, no record that you exist. Two people running identical forks produce completely separate systems that cannot see each other, purely because their secrets differ.

Which means it is free. GitHub gives public repositories unlimited Actions minutes. A private fork would burn a monthly quota on a job that runs 96 times a day.

Which means the run logs are public. That is the cost side of the trade, and it is why job IDs and CRNs are hashed before they reach the log. See what the public log shows.

And there is nowhere for your data to go. The question "can whoever wrote this see my jobs" has a structural answer rather than a promise. There is no server to send them to. The only network calls Qoffee makes are to IBM and to your own webhook.

The relevant code can be found in the qoffee/ folder in the repository.