By Shahid MalikI added external uptime monitoring to Tabeer.ai — a check that pings the site independently of anything running on the server itself, so an outage still gets caught even if the whole EC2 instance is unreachable. UptimeRobot's API is straightforward and well documented for the read side. The write side has a gap worth knowing about before you build automation around it.
Verifying the Key First
Given a Main API Key, the first thing worth doing is confirming it's actually valid and seeing what's already there — not assuming a clean slate:
curl -X POST "https://api.uptimerobot.com/v2/getAccountDetails" \
-d "api_key=u..." -d "format=json"
This came back with a real, active account — free plan, 50-monitor limit, 5-minute check interval — and, unexpectedly, one monitor already configured (the homepage, presumably added through the dashboard at some point). getMonitors confirmed it: status up, checking every 5 minutes. Good baseline, worth knowing about before adding anything new on top of it.
Where It Broke
I wanted two more monitors: one hitting a lightweight backend endpoint (so a "frontend fine, backend down" scenario gets caught separately from a full outage), and one on the highest-value conversion page. Both calls to newMonitor — with only the documented required fields (friendly_name, url, type) — came back with:
{"stat":"fail","error":{"type":"access_denied","message":"You are not allowed to use some settings with your current plan."}}
That message is worth pausing on: it says "settings," which reads like a specific parameter is the problem. It isn't. I stripped the request down to the three required fields, with and without format=json, with and without an explicit interval — same error every time. The one monitor that already existed (created through the dashboard, not the API) works completely normally; the read endpoints (getAccountDetails, getMonitors) work completely normally. Only monitor creation via the API is blocked.
The most consistent explanation, based on the account being brand new (registered the same day): UptimeRobot appears to restrict API-based monitor creation on new free-tier accounts, independent of the account's monitor count being nowhere near its 50-monitor cap. Nothing in their API docs states this as a rule — it just fails silently with a generically-worded permission error.
What Actually Worked
Adding monitors through the dashboard UI directly. Same account, same plan, same monitor limit — just not gated the same way the API is. If you're setting this up and hit access_denied on newMonitor, don't spend time debugging your request payload; go add it by hand instead. Two minutes per monitor, no API involved.
The Actual Lesson
Read-access and write-access to the same API can have different, undocumented eligibility rules — and a generic access_denied error won't tell you which. Before concluding your request is malformed, test with the absolute minimum required fields, and if that still fails identically, check whether the account (age, plan, tier) rather than the request is the actual constraint. It's a five-minute check that saves a lot of time spent debugging a payload that was never the problem.
If you're setting up monitoring or alerting for a Django/Nuxt project and want a second opinion on what's actually worth watching (and where free-tier gotchas like this one are hiding), get in touch.