Giving Tabeer.ai a Public Status Page — and a /status Route That Actually Points to It

I'd already documented UptimeRobot's free-plan API limitation — newMonitor calls failing with a generic access_denied on a brand-new account. Building Tabeer.ai a public status page ran into the same wall from a different angle: status-page creation isn't exposed to automation at all on this plan, monitor-creation restriction or not. Here's what that meant in practice, and the small piece of it that actually lives in the Tabeer.ai codebase.

No API Path, So Dashboard It Is

UptimeRobot's status pages (PSPs) are created through the dashboard — Status Pages → Add Status Page — not through a scriptable endpoint on this plan. Given the same account had already refused API-created monitors for an unrelated reason, I didn't spend time probing whether a status page API call would behave differently; the dashboard path is two minutes and doesn't depend on guessing at undocumented plan restrictions.

The result: https://stats.uptimerobot.com/f04rwMfw7A, showing the existing homepage monitor, live and publicly reachable with no login required.

The One-Line Trap: Badge Embed Code Isn't the Page URL

UptimeRobot's dashboard offers an embeddable badge — an <iframe> snippet pointing at badge.uptimerobot.com/psp/<id>. That's an image endpoint for embedding a status indicator somewhere else, not the URL of the actual status page. The two share the same PSP ID but resolve completely differently:

https://badge.uptimerobot.com/psp/<id>   → embeddable status badge (image/iframe)
https://stats.uptimerobot.com/<slug>     → the actual public status page

Worth flagging because the badge snippet is what the dashboard surfaces most prominently when you go looking for "the link" — the real page URL is a separate field, usually labeled something like "Your status page is available at."

A Thin /status Page on Tabeer.ai, Not a Rebuild

Rather than try to mirror UptimeRobot's status data inside the Nuxt app — which would mean either polling their API from the frontend or proxying it through Django, for no real benefit over just linking out — tabeer.ai/status is a small, honest page:

<template>
  <div class="container-industry section-pad-compact ...">
    <h1>System status</h1>
    <p>Checked independently every 5 minutes by UptimeRobot...</p>
    <a href="https://stats.uptimerobot.com/f04rwMfw7A" target="_blank" rel="noopener noreferrer" class="btn-primary">
      View live status page →
    </a>
    <!-- one row per monitored service, each also linking out -->
  </div>
</template>

It lists what's being monitored (in plain language, not scraped data) and sends visitors to UptimeRobot's own page for the actual live numbers — UptimeRobot already solved "render uptime history reliably," and re-solving that inside the app would be effort spent on a problem that doesn't need solving twice. Linked from the site footer under "System status," next to Privacy Policy and Terms, so it's discoverable from every page without cluttering the main navigation.

What's Still Just One Monitor

Right now the status page reflects a single check: the homepage. The next step — not yet done — is adding monitors for the backend API root, a database-touching endpoint (so "frontend up, DB down" shows separately from a full outage), the /exams conversion page, and Flower's dashboard (Celery's health, indirectly, since Flower depends on the same broker connection) — all through the dashboard, for the same API-restriction reason as the first monitor. A status page with one monitor on it is honest about what it's actually watching; it just isn't the full picture yet.

The Actual Takeaway

Two separate UptimeRobot integrations on this project — monitor creation and now status-page creation — both turned out to be dashboard-only on a free-plan account, for reasons the API's error messages don't actually explain. When automation hits a wall like that, the fix isn't necessarily more debugging of the request — sometimes it's confirming the constraint is real (test with minimal required fields, check if it's account-level rather than request-level) and then just doing the two-minute manual step instead of burning an afternoon on it.

If you're setting up status pages or monitoring for a small production app and want the actual constraints of your plan mapped out before you build automation around it, get in touch.