Migrate from UptimeRobot to Hyperping

Switching uptime providers feels risky because any gap in coverage means missed downtime. Follow this guide to rebuild your UptimeRobot setup in Hyperping step by step, run both tools in parallel, and switch off the old account only once the alerts match.

Concept mapping

Most UptimeRobot concepts have a direct equivalent in Hyperping. Use this table to translate your current setup before you start.

UptimeRobotHyperping
Monitors (HTTP, ping, port)Monitors with HTTP, ICMP, port, and DNS checks
Keyword monitorsMonitors with a text body assertion
Heartbeat monitorsHealthchecks for cron jobs and scheduled tasks
Alert contactsNotification channels and escalation policies
Maintenance windowsMaintenance windows
Status pages (PSP)Status pages with subscribers

Migration steps

  1. Inventory and export your UptimeRobot setup

    List every monitor with its URL, check interval, keyword if any, and the alert contacts it notifies. Export the list as CSV from the dashboard or pull it from the API, whichever your plan supports.

    Flag heartbeat monitors separately: they become healthchecks in Hyperping, not regular monitors.

  2. Recreate your monitors in Hyperping

    For fewer than 20 monitors, 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
    }

    Recreate keyword monitors as HTTP monitors with a text body assertion, and heartbeat monitors as healthchecks.

  3. Rebuild alerting and escalations

    Connect the notification channels your alert contacts map to: email, SMS, Slack, webhooks, and more.

    Then create escalation policies to define who gets alerted, in what order, and how long to wait before escalating.

  4. Run both tools in parallel

    Keep UptimeRobot 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 monitor, a wrong interval, or a threshold worth tuning.

  5. Point your status page and switch off UptimeRobot

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

    Once the parallel run is clean, pause your UptimeRobot monitors and close the account.

What happens to my historical uptime data?

Historical metrics cannot be transferred between providers, so export any reports you need before closing your UptimeRobot 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.
  • Broader coverage: browser checks and cron job monitoring sit alongside HTTP, ICMP, port, and DNS checks.
  • Flat pricing: plans are based on monitors, not seats, so your whole team can log in.

Migration resources

Next steps