Skip to main content
Alert connectors let external monitoring systems raise incidents inside Squasher. Connector-created incidents have the integration source type and flow through the project’s existing notification routes. Sources and destinations are separate. A source receives an alert from CloudWatch, Alertmanager, Grafana, Datadog, PagerDuty-compatible producers, or a generic sender. A notification destination sends the resulting Squasher incident to responders.

​
Operations

Management operations require project read or write permission. The inbound endpoint authenticates AWS connectors with the SNS signature and exact topic ARN. Webhook connectors use the write-only secret returned at creation or rotation; the provider setup page specifies whether it belongs in a bearer header or payload. Inbound endpoints are rate-limited at the edge before application processing. A 429 response is retryable; preserve the original event identity and use exponential backoff with jitter.

​
Providers

​
Create AWS CloudWatch

​
Create a generic webhook

Create and rotate responses include a setup object. Store its secret in a secret manager; subsequent reads return only secret_prefix. Because that secret is returned only once, create and rotate requests do not accept Idempotency-Key and official clients do not retry them automatically. If the response is interrupted, list the project’s connectors before creating another one, then rotate the existing connector if you need a new credential. Rotation starts a 24-hour overlap window for the previous secret. Update the source during that window, verify a provider-specific firing and recovery test, then let the old credential expire. AWS connectors do not expose this operation because SNS signatures authenticate their requests. The test operation checks that the connector is enabled and reports whether Squasher has received a provider delivery. It does not manufacture an incident or pretend to test the upstream vendor. Use listDeliveries to inspect recent opened, updated, resolved, ignored, and failed outcomes without exposing raw payloads or credentials.

​
Paginate delivery history

Request a page size from 1 to 100 to receive a cursor page. Omit cursor on the first request, then pass the returned next_cursor unchanged until it is null. The cursor is opaque; do not parse or construct it.
The TypeScript client can walk every page without manually handling cursors:
The CLI exposes the same contract with --limit and --cursor. MCP agents can discover it with search("alertConnectors.listDeliveries"); omit cursor on the first execute call and reuse the response’s next_cursor on the next call. Calling the endpoint without limit or cursor still returns the legacy first-page array for compatibility. New integrations should always request limit so they can continue beyond the first 50 records. default_severity is a project-configured incident-severity key, not a closed enum. Existing legacy keys and additional ranks such as sev-8 remain valid; the value is bounded to 64 characters. Deleting a connector immediately revokes its credentials and resolves any active incidents owned by that connector. The connector disappears from management APIs, while listDeliveries remains available for that connector ID and project during the 90-day delivery-audit retention window. Save the connector ID before deletion. The response contains only sanitized delivery metadata; another project cannot read it. The 90-day ledger bound applies to every outcome. Project deletion removes the history immediately. Delivery rows expire even when the linked incident is still open; the incident and its timeline remain available. Once a delivery identity has aged out, reusing that identity can process a new request, subject to the normal lifecycle-ordering checks. Use client.alertConnectors.* in @squasher-ai/api-client, squasher alert-connectors, or MCP search("alertConnectors"). See Inbound alert connectors for lifecycle, deduplication, security, and troubleshooting guidance.