An address for every integration
Each OpsPing integration gets a unique inbound address — <id>.<token>@alerts.ops-ping.com. Mail sent to it becomes an alert on that integration, with all of its routing, escalation, and notification rules applied.
backup-jobs.9f3k2mq7v1@alerts.ops-ping.com
The token is the auth. Anyone who has the address can create alerts on that integration — which is why you can rotate it (below).
Legacy tools become alert sources
Backup jobs, hardware monitors, security scanners, cron scripts, that old NAS that can only email — plenty of useful systems never learned to speak webhooks. Point their mail at the integration address and they're first-class alert sources. Configure once, in the tool's own notification settings.
Priority in the subject line
Tag the subject with [P1]–[P5] to set the alert's priority. A failed nightly backup and a dying RAID controller shouldn't wake the same person.
To: backup-jobs.9f3k2mq7v1@alerts.ops-ping.com Subject: [P2] nightly db-backup failed on db-04
Delivery details that matter at 3 AM
Dedupe by messageId. Flaky mail servers retry. The same message delivered twice creates one alert, not three pages.
Address rotation. Address posted to a public tracker, or the person who set it up left? Rotate the token from the integration settings — the old address stops accepting mail, and you get a fresh one.
Pair inbound addresses with webhook integrations for the rest of your stack — same integrations page, same routing rules.
Coming from Opsgenie?
If your runbooks lean on @opsgenie.net email integration addresses, that's one of the features that dies with the platform. OpsPing keeps the pattern: per-integration inbound addresses with subject-line priority, dedupe, and rotation. Our migration guide covers moving integrations over, and the API reference has the rest.
Try it now: create a free trial, add an integration, and send yourself an alert from the command line — mailx -s "[P3] hello" backup-jobs.<token>@alerts.ops-ping.com. Start free →