Webhooks
12.3. Webhooks — Event-Driven Triggers
Subscribing to external events
hermes webhook subscribe github --event pull_request
hermes webhook subscribe github --event issues
Unlike cron (which proactively follows a schedule), webhooks let the agent react — when a new PR, new issue, or any event from an external system (GitHub, a custom service) happens, Hermes receives the signal and processes it immediately, without waiting for the next periodic check.
Combined with Development (chapter 15) and Monitoring (chapter 18)
This is exactly the mechanism behind automatically reviewing a PR the moment it is opened (15.6) or automatically answering a new issue the moment it is created, instead of having to wait for a periodic cron job to scan around and discover it.
Cron vs webhook — choosing the right tool for the right need
| Criterion | Cron | Webhook |
|---|---|---|
| Reaction latency | On the set cycle (minutes to hours) | Near-instant |
| Best for | Work that needs periodic rollups and is not urgent | Work that must react as soon as an event happens |
| Cost | Runs on schedule whether or not anything new happened (unless a pre-filtering script is used) | Only runs when there is actually an event |
Notes
- For important events that need a fast reaction (a PR that urgently needs review, an issue reporting a production bug), prefer webhooks over waiting for the next periodic cron job to scan around.
- For rollup/report work that does not need an immediate reaction (weekly reports, news digests), cron remains the simpler and more predictable choice than webhooks.
- Both can be combined for the same purpose: webhooks handle the fast reaction to important events, while cron acts as a periodic safety-net sweep to catch the cases a webhook may have missed (temporary connection loss, rate limits).