Oodle / Workshop materialBack to workshop hub
Masterclass

Recipe: inbox / queue monitor

Scan a queue on a clock and summarise risk instead of reading it by hand.

Recipe: inbox / queue monitor

For anyone whose Build brief idea is still blank. Swap in your own systems and this is yours in ten minutes.

The pain it copies: something arrives in a queue (a mailbox, a ticket list, a log stream) faster than anyone checks it by hand, and risk sits unnoticed until it's a problem. David's mailbox monitor is the reference case: built on a train with patchy signal, still caught real risk.

The five blocks

  • Trigger: a clock. Hourly or daily is enough to start.
  • Input: the queue itself (a mailbox, a ticket board, a log source) and whatever counts as "risk" in it: an age threshold, a keyword, a status that's stuck too long.
  • Work: scan the queue, group what it finds by risk category, and summarise it in one view rather than a raw list.
  • Check: the summary's counts match what a human would get counting by hand on a small sample. If they don't, the categorisation logic is wrong, not the check.
  • Output: a short summary: counts by category, the worst few examples, nothing that requires opening every item to understand.

Swap in your own systems

  • Start read-only. This recipe surfaces risk; it doesn't act on it. Escalation and remediation are a second build, not this one.
  • No obvious queue? Any list that grows faster than someone reviews it works: a shared drive, a backlog, an approvals list.
  • To make the Trigger real: a Claude Code routine on an hourly schedule is the whole implementation of this block.

Done when

It scanned a real queue on its own trigger, produced a summary a human didn't have to build by hand, and you checked the counts against a manual sample.

Original Markdown
# Recipe: inbox / queue monitor

For anyone whose Build brief idea is still blank. Swap in your own systems and this is yours in ten minutes.

**The pain it copies:** something arrives in a queue (a mailbox, a ticket list, a log stream) faster than anyone checks it by hand, and risk sits unnoticed until it's a problem. David's mailbox monitor is the reference case: built on a train with patchy signal, still caught real risk.

## The five blocks

- **Trigger:** a clock. Hourly or daily is enough to start.
- **Input:** the queue itself (a mailbox, a ticket board, a log source) and whatever counts as "risk" in it: an age threshold, a keyword, a status that's stuck too long.
- **Work:** scan the queue, group what it finds by risk category, and summarise it in one view rather than a raw list.
- **Check:** the summary's counts match what a human would get counting by hand on a small sample. If they don't, the categorisation logic is wrong, not the check.
- **Output:** a short summary: counts by category, the worst few examples, nothing that requires opening every item to understand.

## Swap in your own systems

- Start read-only. This recipe surfaces risk; it doesn't act on it. Escalation and remediation are a second build, not this one.
- No obvious queue? Any list that grows faster than someone reviews it works: a shared drive, a backlog, an approvals list.
- To make the Trigger real: a [Claude Code routine](https://code.claude.com/docs/en/routines) on an hourly schedule is the whole implementation of this block.

## Done when

It scanned a real queue on its own trigger, produced a summary a human didn't have to build by hand, and you checked the counts against a manual sample.