Liveness and diagnostics, in one call.

check/0 returns everything a /health endpoint needs:

• db, whether the pool can serve a trivial query.
• extensions, installed PostgreSQL extensions and their versions. Worth surfacing because Ergon's behaviour genuinely depends on them: without pg_cron no notification tick runs and every wake path falls back to polling.
• jobs, per-queue counts from ergon.jobs.
• pgmq, per-queue metrics for whichever pgmq queues were asked about.

{ergon, [{ergon_health, [{pgmq_queues, [~"events", ~"receipts"]}]}]}

pgmq queues have to be named because pgmq has no notion of which queues belong to this application, and reporting on every queue in the database would include other applications'. Job queues need no such list: they are rows in ergon.jobs, so the query finds them.

Reading the job counts

runnable is what checkout would take next, and uses the same predicate as jobs_fetch_idx. blocked is the one to watch: those jobs are available but waiting on a workflow parent, so they are invisible to checkout, and a queue full of them looks idle while holding work. Since a parent that ended failed or discarded never completes, its children stay blocked until an operator intervenes with ergon:cancel/1. Nothing else surfaces that.

A persistently high executing with no throughput means consumers died holding jobs, which is what ergon_reconciler is for.