Migrate from PagerDuty to Hyperping

PagerDuty usually sits at the center of incident response, so this migration is about rewiring a pipeline, not just copying monitors. This guide moves detection, on-call, and status communication into Hyperping, and shows how to keep PagerDuty connected if part of your team stays on it.

Concept mapping

PagerDuty routes alerts sent by other tools, while Hyperping runs the checks itself and covers monitoring, on-call, and status pages in one product. Use this table to translate your current setup.

You don't have to drop PagerDuty on day one. Connect it as a notification channel through the PagerDuty integration, and Hyperping alerts will keep opening PagerDuty incidents for the teams that want them.

Migration steps

1. Map your services and alert sources

   Export your service directory, escalation policies, and schedules from the dashboard or through the API. For each service, note which monitoring tool sends it events and what those checks actually verify.

   Decide which of those checks Hyperping will now run natively as monitors, browser checks, or healthchecks.

2. Create monitors for what PagerDuty was receiving

   For fewer than 20 checks, creating them by hand in the dashboard is usually the fastest path. See Create a monitor.

   For a larger fleet, loop over your inventory with the API, or manage everything as code with the Terraform provider:

   cURLTerraform

   Copy

   curl -X POST https://api.hyperping.io/v1/monitors \
     -H "Authorization: Bearer ${API_TOKEN}" \
     -H "Content-Type: application/json" \
     -d '{
       "name": "Website",
       "url": "https://acme.com",
       "protocol": "http",
       "check_frequency": 30,
       "regions": ["paris", "frankfurt", "amsterdam", "london"]
     }'

   Response201 Created

   {
     "name": "Website",
     "url": "https://acme.com",
     "paused": false,
     "regions": ["paris", "frankfurt", "amsterdam", "london"],
     "http_method": "GET",
     "check_frequency": 30,
     "protocol": "http",
     "follow_redirects": true,
     "expected_status_code": "2xx",
     "uuid": "mon_3GhAQMYGEQuyUH",
     "status": "up",
     "alerts_wait": 0
   }

   Add healthchecks for cron jobs and browser checks for critical user journeys where you previously relied on external events.

3. Rebuild schedules and escalation policies

   Recreate your rotations as on-call schedules, then build escalation policies that page through them in the same order as today.

   Connect your notification channels: push, SMS, phone call, Slack, email, and more.

4. Run both tools in parallel

   Keep PagerDuty active for a few days while Hyperping takes over detection. Route Hyperping alerts into PagerDuty with the integration so the on-call experience stays familiar during the overlap.

   Compare both sides after each incident: a difference points to a missing monitor or an escalation rule worth tuning.

5. Move status communication and wind down

   Publish your Hyperping status page and invite your subscribers. If your public page currently runs on Atlassian Statuspage, bring over its history with the Statuspage importer.

   Then retire the PagerDuty services you replaced, or keep PagerDuty purely as a notification channel.

What you'll gain

• Detection and paging in one product: the monitor that finds the outage is the same tool that pages the engineer.
• Customer communication included: status pages with subscribers ship with every plan, with no extra subscription to manage.
• 18 monitoring regions: checks run from up to 18 locations worldwide, and failures are confirmed from other regions before anyone gets paged.
• Flat pricing: plans are based on monitors, not seats, so growing the on-call roster costs nothing extra.

Migration resources

Next steps