Skip to main content
Inbound alert connectors turn alerts from another monitoring system into Squasher incidents. They preserve the source alert’s lifecycle: a firing event opens or updates an incident, an acknowledged event records an update, and a resolved event closes it. An alert source sends alerts into Squasher. A notification destination sends Squasher incident updates to responders. For example, you can receive a Grafana alert through a source connector, then route the resulting incident to Slack and PagerDuty. See Notifications to configure destinations and routes.

​
Supported sources

AWS CloudWatch

Signed CloudWatch alarm notifications delivered by Amazon SNS.

Generic webhook

A small JSON contract for custom systems and scripts.

Prometheus Alertmanager

Alertmanager webhook v4 batches, including resolved alerts.

Grafana Alerting

Grafana webhook contact-point notifications.

Datadog monitors

Datadog monitor transitions using a managed webhook template.

PagerDuty Events API v2

Events API v2 trigger, acknowledge, and resolve payloads.

​
Lifecycle and deduplication

Each provider adapter extracts two separate identifiers:
  • The alert key correlates lifecycle updates for one source alert. It remains stable from firing through resolution.
  • The event key identifies one delivery. Retrying the same event does not create another incident or repeat the same lifecycle transition during the 90-day delivery-audit and exact-deduplication window.
Squasher also rejects an older lifecycle event after a newer one has been applied. For batched providers such as Alertmanager and Grafana, each alert in the request is normalized and correlated independently. Batch processing is not atomic across the entire request. A mixed batch returns 207 only when valid items committed but malformed provider items were rejected. The response includes counts and safe rejection entries, including one aggregate entry for items beyond the 1,000-item processing bound. Correct rejected items before resending them. An all-invalid batch returns 422. Any persistence failure returns 503, even when another item already committed. Retry that complete request unchanged with backoff; original event identities deduplicate prior commits. Squasher processes each webhook request synchronously with bounded database work. A request can include up to 1,000 provider alerts, but it can apply at most 64 new state-changing alert mutations. If the processing bound or scheduling deadline is reached, Squasher returns retryable 503 with Retry-After: 5. Retry the full request unchanged; already committed event identities are deduplicated. Delivery audit and exact event-key deduplication use a fixed 90-day window for every outcome, including alerts whose incidents remain open. The incident and its timeline remain after detailed delivery rows expire. After 90 days, a previously retained provider event identity can be processed again; source timestamps and current lifecycle state still protect against out-of-order transitions.
Connector-created incidents use the integration source type and flow through the same notification routes as Squasher monitors.

​
Connect and verify a source

1

Create the connector

In Squasher, select the project, open Settings → Integrations, choose the source, and create a connector. You can also use the Alert Connectors API.
2

Configure the source

Copy the generated HTTPS endpoint and authentication value into the monitoring system. Secrets are shown only in the create or rotate response.
3

Send a test alert

Use Check connection to validate Squasher’s connector state, then trigger a test or temporary alert at the source. Verify one incident opens, then send its recovery and verify that the same incident resolves. The check does not fake an upstream vendor delivery.
4

Attach notification routes

Route connector incidents to Slack, webhooks, email, or PagerDuty under Settings → Notifications.

​
Security and secret rotation

  • Squasher accepts connector traffic only over HTTPS and validates each provider’s authentication before parsing the alert.
  • AWS CloudWatch uses the SNS signature and the exact configured topic ARN. Other source connectors use the generated connector credential in the provider-specific location described on its setup page.
  • Store connector credentials in a secret manager. Squasher stores a one-way hash for generated webhook credentials and shows only a redacted prefix later.
  • Rotating a connector secret keeps the previous secret valid for 24 hours. Rotate through the API or dashboard, replace the source value during the overlap, then send a firing and recovery test before the old credential expires.
  • Disable a connector before planned maintenance. Delete it when the source should no longer be able to create or update incidents. Deletion immediately revokes its credentials and resolves active incidents owned by that connector. Sanitized delivery audit records remain readable by connector ID for the fixed 90-day retention window. Project deletion immediately removes the retained audit data.

​
Troubleshooting

Do not replace a stable alert key with a timestamp or retry ID. That causes every delivery to look like a new alert.