Operations and capacity

Running workers, delayed mail checks, the queue and errors — and when to add another worker.

The work with mail is done by the worker — a process that goes through the mailboxes in turn, calls the models and writes drafts. The Operations page (operator, Installation → Operations) shows whether enough of them run. It refreshes every 30 seconds.

What the page shows

Capacity — a verdict in a word:

Verdict	What it means	What to do
capacity is enough	no assistant lags behind its rhythm by more than five minutes	nothing
add a worker	some assistant lags by more than five minutes	raise the concurrency, or start another process
no worker is running	no worker checked in during the last minute	`docker compose ps` and the logs of the `worker` service

Workers — the running processes, their concurrency, which mail systems they serve, which mailbox they hold right now and when they last checked in.

Late mail checks — assistants past their due time by more than a minute (named by organisation and assistant, never by mailbox address).

Job queue — how many wait and run, and how many finished or failed in the last 24 hours. Errors in 24 hours — what went wrong where.

How to add capacity

Raise the concurrency first — in the Worker settings card, the "Mail checks at once per process" field (1–50). A mail check is mostly waiting for the mail and the model, so even a small container copes with more than the default 3. Workers take the change within seconds, no restart.
Another process on the same machine: write in .env how many processes should run in total (WORKER_REPLICAS=2) and run docker compose up -d. The number in .env survives an update too; --scale worker=N would only last until the next docker compose up.
Another machine: a clone of the repository, the same .env with DATABASE_URL pointing at the shared database (the db service's port 3306 must be reachable from there), then docker compose up -d --no-deps worker.

A new worker shows on the page within seconds. Workers split the work through the database by themselves: each mailbox is held by one only, so two checks never meet. A process that crashes only delays that one mailbox until its lock runs out.

The same card sets the default mail check interval (60–86,400 s) for assistants without an interval of their own.

Advanced

WORKER_PROVIDERS=google (a list of graph, google) limits a process to some mail systems only — so a slower provider does not hold up the others, say.
WORKER_ID names a process in the log (hostname:pid by default).
A mail check that left work for later (the per-check limit, more than 200 new messages) queues the assistant again at once, so a flooded mailbox catches up in rounds.

Scaling is a human decision; draften never starts workers by itself.