Subscribe an SNS topic to OpsPing and every CloudWatch alarm pages on-call: ALARM creates the alert, OK closes it, and the alarm name becomes a stable alias — cloudwatch:<AlarmName> — so the open/close loop is deterministic. INSUFFICIENT_DATA creates nothing; flapping metrics don't manufacture pages.
Setup
- Create the OpsPing integration with source type AWS CloudWatch (SNS) and a default service.
- Subscribe the SNS topic to the integration's HTTPS webhook URL.
- Confirm the subscription separately — OpsPing acknowledges confirmation messages but does not confirm on your behalf.
- Force one alarm transition and verify the alert lands with the right priority.
Field mapping
| CloudWatch state | OpsPing behavior |
|---|---|
ALARM | Creates an alert — alias cloudwatch:<AlarmName>, default priority P3, alarm reason as description |
OK | Closes the alert owning that alias |
INSUFFICIENT_DATA | No alert created |
| SNS envelope | Unwrapped automatically — the alarm body is what gets mapped |
| Region, timestamp | Mapped into the alert |
Operational notes
- Alarm names are the identity: keep them stable per condition so
OKalways closes the right alert, and so repeatALARMnotifications dedupe into occurrence counts instead of duplicate rows. - P3 default too loud or too quiet for some alarms? Re-rank with alert policies matched on the integration source or tags — dry-run the chain before saving.
- Planned work: maintenance windows suppress paging for covered alerts (stored, not deferred).
- Burst protection is built in: 300 requests/minute per integration.
Migrating from Opsgenie or PagerDuty?
The SNS topic is the asset — you keep it and swap the subscriber. Opsgenie users: the SNS integration that pointed at Opsgenie's HTTPS endpoint repoints to OpsPing in minutes. See the Opsgenie migration guide for the full cutover order.
FAQ
Does OpsPing confirm the SNS subscription?
No — OpsPing acknowledges SNS confirmation messages but will not confirm the subscription for you. Click the confirmation link (or call ConfirmSubscription) after subscribing the topic; a page delivered before confirmation is the most common setup miss.
What priority do CloudWatch alarms get?
P3 by default, with the alarm reason as the description. If specific alarms must page at P1 — the database, the payment path — tag them in AWS and add an alert policy that sets priority from the tag, or split them onto a dedicated integration.
Why didn't INSUFFICIENT_DATA create an alert?
By design: unknown-state flapping would manufacture noise. Only ALARM creates and OK closes. If a stuck-unknown state matters for a given alarm, model it in CloudWatch (alarm on the metric math) rather than hoping the pager catches it.