Migrate from Pingdom to Hyperping

Pingdom has probably watched your sites for years, so moving away deserves a plan rather than a rushed weekend. This guide walks you through rebuilding your uptime checks, transaction checks, and alerting in Hyperping without a gap in coverage.

Concept mapping

Every Pingdom concept has a home in Hyperping. Use this table to translate your current setup before you start.

PingdomHyperping
Uptime checksMonitors with HTTP, ICMP, port, and DNS checks
Transaction checksBrowser checks that replay user journeys in a real browser
Maintenance windowsMaintenance windows
BeepManager and alerting policiesNotification channels, escalation policies, and on-call schedules
Public status pageStatus pages with subscribers

Migration steps

  1. Inventory your Pingdom checks

    Export your uptime checks from the dashboard or through the API, and note the URL, interval, probe regions, and alerting settings for each. Keep the report exports you care about while the account is still active.

    List transaction checks separately, with the user journey each one scripts: you'll rebuild those as browser checks.

  2. Recreate your monitors in Hyperping

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

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

    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
    }

    Then rebuild each transaction check as a browser check that walks through the same journey: log in, add to cart, submit a form.

  3. Rebuild alerting and escalations

    Connect your notification channels: email, SMS, Slack, webhooks, and more.

    Recreate your alerting policies as escalation policies, so severity and escalation delays match what your team expects today.

  4. Run both tools in parallel

    Keep Pingdom running alongside Hyperping for a few days. Every incident should now be caught twice.

    Compare the alerts on both sides: a difference points to a missed check, a wrong interval, or a threshold worth tuning.

  5. Point your status page and switch off Pingdom

    Publish your Hyperping status page, move your custom domain, and invite your subscribers.

    Once the parallel run is clean, pause your Pingdom checks and close the account.

What happens to my historical uptime data?

Historical metrics cannot be transferred between providers, so export the Pingdom reports you need before closing the account. Hyperping starts computing uptime, response times, and reports from the moment each monitor is created.

What you'll gain

  • One tool instead of several: monitoring, status pages, on-call schedules, and escalation policies live in the same product.
  • 18 monitoring regions: checks run from up to 18 locations worldwide, and failures are confirmed from other regions before an alert fires.
  • User journeys covered: browser checks live in the same dashboard as your uptime checks, with no separate product to manage.
  • Flat pricing: plans are based on monitors, not seats, so your whole team can log in.

Migration resources

Next steps