Migrate from UptimeRobot
One-click import of your UptimeRobot monitors into HowlOps — plus a manual checklist for channels and status pages.
Overview
HowlOps imports your UptimeRobot monitors directly over the UptimeRobot API. Notification channels and status pages are still a short manual step (they don't map one-to-one). Nothing in UptimeRobot is ever modified — the import only reads.
Time: a few minutes for monitors, plus a little for channels/status pages Prerequisites: a UptimeRobot API key; a HowlOps account
One-click monitor import (recommended)
- In HowlOps, go to Settings → Import (or start it from the onboarding wizard).
- Choose UptimeRobot and paste your main API key (UptimeRobot: My Settings → API → Main API Key). A read-only key is enough — the import only reads, and HowlOps never stores your key.
- Click Load items to see a preview table of every monitor and what it maps to. Rows that can't be imported are shown in yellow with the reason.
- Tick the monitors you want and click Import. A progress bar shows
Importing 34/120…; a problem with one monitor never stops the rest. - You get a summary —
117 imported, 3 skipped— and a Download report CSV.
What gets imported
| UptimeRobot type | HowlOps equivalent | Notes |
|---|---|---|
| HTTP(s) (type 1) | HTTP / HTTPS monitor | Direct equivalent |
| Keyword (type 2) | HTTP monitor + keyword check | exists → must contain, not exists → must not contain |
| Ping (type 3) | Ping (ICMP) monitor | Host taken from the monitor URL |
| Heartbeat (type 5) | Heartbeat | |
| Port (type 4) | not imported | HowlOps has no TCP port monitor type — see below |
- Port monitors are skipped with a reason in the report. HowlOps has no raw TCP port check; for most "is the service up" cases, recreate them as an HTTP monitor against the service's health endpoint.
- Check intervals are clamped up to your plan's minimum and a note is added to the report (UptimeRobot Free = 5 min; HowlOps Uptime Free = 120 s, and paid plans go faster). Nothing fails just because an interval was too fast for your plan.
Re-running is safe
Every import is idempotent — HowlOps remembers which UptimeRobot monitor created which HowlOps monitor, so a second run updates or skips rather than duplicating. If an import is interrupted (e.g. a deploy restarts the service mid-run), just run it again.
Manual steps (channels & status pages)
The rest of the migration is a short manual checklist. The concepts map closely between the two platforms.
Concept mapping
| UptimeRobot | HowlOps equivalent | Notes |
|---|---|---|
| HTTP(S) monitor | HTTP / HTTPS monitor | Direct equivalent |
| Ping monitor | Ping (ICMP) monitor | Direct equivalent |
| Port monitor | none | HowlOps does not have a TCP port monitor type. For most "is the service up" cases, use an HTTP monitor against the service's health endpoint instead. |
| Keyword monitor | HTTP monitor + keyword check | Keyword check is a setting on the HTTP monitor |
| Alert contact | Notification channel | HowlOps calls them "channels" |
| Status page | Status page | More customisation options available |
| Maintenance window | Maintenance window | Same concept |
Monitors themselves are handled by the one-click import above — you don't need to recreate them by hand. The steps below cover the parts the importer doesn't touch: notification channels and status pages.
Step 1: Recreate notification channels
In Integrations → + Add Channel, recreate each alert contact:
| UptimeRobot contact type | HowlOps channel type |
|---|---|
| Slack | Slack (Incoming Webhook) |
| Discord | Discord (Incoming Webhook) |
| Webhook | Custom Webhook |
| PagerDuty | PagerDuty |
| Telegram | Telegram (bot token + chat ID) |
After adding each channel, click Send Test Alert to verify it works before assigning it to monitors.
Step 2: Assign channels to monitors
For each monitor:
- Open the monitor and click Edit.
- In the Notifications section, add the appropriate channels.
- Click Save.
Step 3: Recreate your status page
- Go to Status Pages → + New Status Page.
- Give it the same name and select the same monitors.
- If you had a custom domain on UptimeRobot, follow the custom domain setup in Tutorials: Public status page.
Step 4: Validate and cut over
Before disabling UptimeRobot:
- Let HowlOps run in parallel for at least 24 hours to confirm monitors are checking correctly.
- Trigger a deliberate test failure (take down a test endpoint briefly) to confirm alert delivery.
- Verify the status page looks correct.
Once you are confident everything is working:
- Disable or delete monitors in UptimeRobot.
- Update your DNS or subscriber links to point to the new HowlOps status page URL.
Differences to be aware of
- Check intervals: HowlOps Uptime Free has a 120-second minimum (vs. UptimeRobot Free 5-minute). Paid Uptime plans get faster intervals: 60 s on S, 30 s on M, down to 15 s on L.
- Probing regions: HowlOps probes from four global regions — Nuremberg (EU), Helsinki (EU), N. California (US), and Singapore (Asia) — so you keep worldwide coverage when cutting over from UptimeRobot's checkpoints.
- Heartbeats: UptimeRobot does not have a heartbeat feature. If you were monitoring cron jobs via HTTP with a health endpoint, consider switching to native heartbeats for more reliable detection.
- On-call and escalation: Not available in UptimeRobot. Set up escalation policies in HowlOps to ensure alerts are not missed.
What's next
- Concepts: Monitors: understand all monitor options
- Concepts: Escalation: set up escalation policies
- Tutorials: Public status page: configure your new status page
Was this page helpful?