Connector tiers (CON-014)

Embed
Preview of the card
<a href="https://forumulate.com/p/watchtower/docs/tiers"><img src="https://forumulate.com/api/public/orgs/watchtower/spaces/docs/pages/9beeb848-a6b6-40df-a7c7-dc7f4332df60/social-card.svg?v=3e7ae33eec8b" alt="Connector tiers (CON-014)" width="600" height="315"></a>

Connectors are ranked by how many teams ask for them and how much of an incident they touch. The tier sets what we build first, how we test it and what support to expect. Every connector is our own code over the provider's public API; none embeds a third-party observability product.

Tier 1: built, tested end to end, supported first

Connector

What it does

Status

Slack

Alert threads, buttons (Ack, Resolve, Silence 1h, Declare incident), /wt commands, incident channels

Phase 3 (C1)

Microsoft Teams

Adaptive Cards with the same actions

Phase 3 (C1)

GitHub

Commits for releases, deployments, PR comments, issues from traces

Phase 3 (C2)

Jira

Create and two-way sync tickets

Phase 3 (C3)

PagerDuty-compatible

Events v2 compatible intake (/v2/enqueue)

Phase 3 (C4)

Gatus

Inbound alerts and the health endpoints Gatus polls

Phase 3 (C4, H1, H2)

Support: a regression in a tier 1 connector is a release blocker. Each has an integration test against a recorded or fake provider in the gate, a runbook page, and a signature or token check on every inbound request. We follow provider API changes and aim to ship a fix within two business days of a provider breaking change.

Tier 2: built after tier 1, same code quality, lighter support

Connector

Notes

GitLab

Commits, deployments, issues (Phase 3, C2)

Linear

Issues with two-way sync (Phase 3, C3)

Discord

Webhook channel

Opsgenie-compatible

Intake API (/v2/alerts) and the importer (Phase 3, C4, O2)

Support: best effort; fixes ship in the normal release train. A tier 2 regression is not a release blocker unless it loses data or leaks a secret.

Long tail: webhook and Apprise

Anything else is reached through the signed webhook receiver (HMAC X-Watchtower-Signature, idempotency key header) or through Apprise running next to your Watchtower. We document the payload; we do not build or test a connector per service. If a long-tail service becomes common, it moves to tier 2 and gets a native channel.

Rules every connector follows

  • Tokens are sealed with AES-256-GCM (HKDF info wt/connector-secret/v1, AAD = project and connector id), shown once at most, never logged and never in audit events.

  • Inbound requests are verified before any work: Slack v0 HMAC with a 5-minute window, Bot Framework JWT for Teams, shared secrets or HMAC for the rest.

  • A chat user acts only as the Watchtower user they are linked to, with that user's role. An unlinked user gets a prompt to link their account and no action runs.

  • Outbound calls go through the SSRF guard; private addresses are refused in production builds.

  • Delivery is at-least-once: a retried notification may repeat a message, and where the provider allows it we update in place instead.

Updated