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.
Not shown yet, because it doesn't exist yet: a Certified tier, once
etminan-verifier plugins install <name> ships (see the
roadmap) — a plugin that's been reviewed and can be installed with one command instead of a
manual allowlist-by-hand copy. Until then, every plugin below is a copy-and-verify starting
point, not a one-click install.
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 a future certified catalog would eventually let others install with one command instead of a manual allowlist-by-hand copy.
etminan