Migration guide
DownForReal has a real importer for the move: you export your monitors from UptimeRobot, hand us the file when your instance is provisioned, and we run the converter and the loader against your fresh Uptime Kuma instance as part of setup. Your monitors arrive with the names, targets, and intervals from the export, and a written summary tells you exactly what landed and what did not.
Why people move
Most migrations we see begin with one of these, and the importer exists so that acting on them does not turn into an evening of retyping URLs into a new dashboard.
A monitor that checks from one place can only report what that one place can see, so a routing problem near the checker reads exactly like a dead site. On DownForReal, probes in New York, Frankfurt, and Singapore re-check every down result, and the alert goes out only when at least two of the three agree.
UptimeRobot sells tiers built around how many monitors you run, with shorter intervals and further features placed in the higher tiers as the list grows. DownForReal sells one plan at one flat price, and the plan already contains the confirmation vote, the status pages, and a 60-second minimum interval.
Plenty of people evaluating a move already run Uptime Kuma somewhere, or have wanted to, and would rather keep its dashboard and monitor types than learn a second system. Here it arrives hosted, with your UptimeRobot list converted into it.
Step one: export
The importer takes either shape, so use whichever one your account already gives you. Both produce the same conversion on our side.
Call the UptimeRobot API v2 getMonitors method and save the JSON response to a file. The importer reads the top level monitors array from that response, which carries every monitor with its type, target, keyword, port, and interval fields intact.
Build a CSV file with a header row of friendly_name, url, type, interval and one row per monitor. The columns keyword_value, keyword_type, and port are optional and are used when present. The type column takes the UptimeRobot type numbers 1 to 5, or the words http, keyword, ping, port, and heartbeat.
Send us the export when your instance is provisioned. From there the import runs as part of setup, and the remaining steps on this page describe what happens to the file, in order, so you can check our work afterwards.
Step two: import
The conversion runs in two tools, a converter and a loader, and each one reports as it goes. Nothing about the result is a surprise you discover later.
It writes a backup file in the shape Uptime Kuma has always used, plus a plain language summary beside it. The summary lists how many monitors were converted, how many were skipped and why, and every change the tool had to make along the way.
Uptime Kuma 2.x has no screen that takes a backup file in, so the loader speaks to your instance the same way the dashboard does, over its socket connection, and adds every monitor through the same path the Add Monitor page uses. It prints one line per monitor with the outcome, and a monitor that fails is named, with the reason the server gave.
Open the summary next to your new instance and compare. Monitors that were active in UptimeRobot start checking right away, and monitors that were paused arrive paused, so the list behaves the way it did on the other side from the first minute.
What lands automatically
The five UptimeRobot monitor types convert across with their working parts intact, and the edges of the conversion are stated in the open rather than discovered afterwards.
HTTP(s) checks land as http monitors on the same URL. Keyword checks land as keyword monitors with the keyword carried over, and an UptimeRobot keyword that must not exist becomes an inverted keyword check. Ping checks land on the hostname, port checks land on the hostname and port (with the port taken from the UptimeRobot service sub type when the export carries no custom port), and heartbeat monitors land as push monitors, which work the same way from your side: your job calls a web address on a schedule, and the monitor goes down when a call is missed.
Intervals below your plan floor are raised to the floor, which is 60 seconds on the paid plan and 300 seconds on a trial, and the summary lists each monitor that was changed. One import holds at most 100 monitors, and anything past that is skipped, listed in the summary, and can be imported in a second run. A monitor missing something it cannot work without, such as a keyword monitor with no keyword or a port monitor with no usable port, is skipped and named in the summary with the reason.
UptimeRobot does not export notification channels in a form Uptime Kuma can take, so your email, Slack, and webhook alert channels are added once by hand inside your new instance after the import. One address change rides along with that step: a converted heartbeat monitor gets a fresh push address generated by the new instance, so the job or cron task that called the old UptimeRobot address has to be pointed at the new one, and the import summary calls out every monitor where this applies.
What it costs
The migration runs as part of setting up your instance on the standard plan, and the trial runs the full plan for 14 days while your UptimeRobot account keeps running untouched beside it.
Or $75 a year on the annual plan, which brings the same plan down to $6.25 a month across the year.
Up to 100 monitors at a 60-second minimum interval, down alerts confirmed by the three-region vote before they page you, status pages mirrored off-site, the UptimeRobot importer for your existing list, and email support from the operator who runs the fleet.
Still weighing the switch itself? The UptimeRobot alternative page compares the shape of the two offers side by side.
Questions
The API v2 getMonitors response is the complete route, because it carries every field the converter reads, including keyword settings and port sub types. The CSV route suits anyone who would rather assemble the list in a spreadsheet, and it converts the same way as long as the header row carries friendly_name, url, type, and interval, with keyword_value, keyword_type, and port added where a monitor needs them.
One import holds at most 100 monitors. Anything past that is skipped rather than dropped silently, listed in the import summary, and can be imported in a second run. The plan itself also covers up to 100 monitors, so a list larger than that is worth a conversation with us at support@downforreal.com before you export.
Your UptimeRobot account is never touched by the import, and the sensible pattern is to run both services side by side through the 14-day trial while they watch the same services. Imported monitors that were active start checking right away, and you cancel the old account only when the alerts from the new one have earned your trust.
They arrive paused. UptimeRobot status 0 means the monitor was paused, and the converter carries that state across, noting each one in the summary so you can see the pause was deliberate rather than a conversion error.
Notification channels are not part of an UptimeRobot monitor export, so the converted backup carries an empty notification list and there is nothing for the loader to add. Email, Slack, and webhook channels are set up once inside your new instance, where they then attach to your monitors the usual Kuma way. Heartbeat monitors carry one related manual item: the new instance generates a fresh push address, and the job that called the old address needs pointing at the new one.
On the hosted service, no. The loader signs in with a user name and password, which an account with two factor authentication already turned on would refuse, and the hosted import runs during setup, before two factor authentication is switched on for your account. You turn it on afterwards, over a fully imported instance.
Start the trial, send the export, and read the import summary against your new instance while UptimeRobot keeps watching everything it watched yesterday. Two weeks of both services paging or staying quiet on the same incidents will tell you whether the move earned its place.