Alert Integration Catalog

All ways alerts are sent. Cataloged.

Why catalog integrations

Most teams send alerts via 5+ channels: Slack, PagerDuty, Opsgenie, email, ticketing, custom webhooks. Without a catalog, no one knows what fires where.

When a channel breaks (PagerDuty outage, Slack incident), responders need to know which alerts depend on it.

When onboarding a new tool, the catalog tells you what wiring already exists.

What goes in

Channel name, owner team, transport type, secrets store reference, last-tested date, last-fire timestamp, fallback channel.

For each channel: which alert routes target it, in which Alertmanager/Datadog config block.

Cost per channel: vendor fees, event counts, retention.

How to keep it current

Generate from Alertmanager's config and Datadog's monitor APIs nightly. Drift between catalog and live config is a defect.

Synthetic test fires once per week per channel. A channel that didn't deliver a test fire in 7 days is flagged.

Owner team pull from Backstage or your service catalog. Don't duplicate ownership data.

What it unlocks

Vendor migrations. Switching from Opsgenie to PagerDuty requires knowing every config block referencing the old provider.

Compliance audits. SOC2 controls ask which alerts notify which channels for which severities.

Incident reviews. The first question after a missed page is: was the channel up.

Build it small first

A YAML file with 50 lines is fine. Skip the SaaS catalog tool until you outgrow YAML.

Make ownership the mandatory field. Skip if no team owns the channel.

Plan to delete unused channels quarterly. Channels with zero fires in 90 days are removal candidates.