A running list, not a fixed one: change-correlation and notification-channel plugins under the shared Etminan Plugin API, each with an honest status, not a blanket "supported" claim. As more get written — by us or by you — they get added here.
No in-process HTTP clients, no hardcoded integrations: every ticket system and paging tool Etminan talks to is a separately-vetted, allowlisted, SHA-256-pinned external script. This page lists what exists today across both plugin categories.
Ships in the binary itself, not a plugin — always available, no allowlist entry needed.
Real code built directly against the target system's documented (or actual, read-from- source) API — not yet verified against a live instance. Test against your own before production use.
etminan-verifier plugins install/update/list now ships in the
verifier binary — a certified-install path that verifies a catalog manifest's Ed25519
signature against a compiled-in trust anchor before trusting anything it lists, then
downloads, hashes, and allowlists a plugin in one command instead of a manual copy-hash-
paste. Not yet live: nothing publishes a real, signed catalog manifest at its default
URL yet, so there's no Certified tier to actually mark a plugin with below — every
plugin on this page is still a copy-and-verify starting point today. Once a real catalog
release exists, request-tracker and freeitsm (already listed as
change-source entries in
deploy/plugins-catalog.json.example) are the first candidates
to pick up the tag.
Queries whichever change/ticket-management systems are configured for a pending baseline change near the time it was first seen — purely informational, never a gate. Full contract and config in Change correlation.
Searches RT via TicketSQL for a ticket mentioning the host, in a window around the finding's first-seen time. Built against RT's REST2 API and documented TicketSQL syntax.
Needs: curl, jq, GNU date(1)
Same correlation model against FreeITSM's REST API v1 — built directly from its real endpoint and response source, not a guessed generic-ITSM shape. Two limitations disclosed in the plugin itself: no upper-bound time filter, title-only search.
Needs: curl, jq, GNU date(1)
Every finding can fan out to any combination of these, each independently filterable by severity. Full contract and config in Notification channels.
A local sendmail call, not a plugin — always available, no
allowlist entry needed. Every channel below is an external plugin under the same
Plugin API.
One Events API v2 incident per finding, deduplicated per host so a repeat finding correlates into one incident instead of paging fresh every cycle.
Needs: curl, jq
One digest message per notification cycle via an incoming webhook — a noisy cycle with many findings is still a single message, not a flood.
Needs: curl, jq
The escape hatch, and the template to copy for a fully custom channel — posts the findings array to any HTTPS endpoint, optionally reshaped via a jq filter first.
Needs: curl (jq only if reshaping)
Writing a plugin for a system not listed here is the same recipe as every reference implementation above — see writing a new plugin in the Plugin API docs. No Rust code, no verifier rebuild: a script satisfying one category's input/output contract, allowlisted by name, path, and pinned SHA-256. Contributions are welcome — a well-tested plugin against a real instance of its target system is exactly the kind of thing this directory exists to grow, and exactly what the certified catalog (mechanism shipped, publishing pipeline still pending — see above) would let others install with one command instead of a manual allowlist-by-hand copy.
etminan