Scheduled Monitoring in PolyApiIDE: automatic checks on a timer

I build PolyApiIDE, and one question comes up regularly: "can this just check itself while I'm not watching?" Yes — that's Scheduled Monitoring. This article covers what it actually does, how to set one up, and, more importantly, the real limits it has that I don't want to hide.

What it is

Scheduled Monitoring takes a saved request, a collection, or a QA scenario and re-runs it automatically on a timer, without you keeping the IDE tab open and watching it. The minimum interval is 5 minutes — you can't go shorter, and that's a deliberate limit, not a temporary gap.

The idea is simple: instead of manually re-running the same request every few minutes to check "is this still working?", you set up the check once and then either look at the result when it's convenient, or get an alert when something breaks.

How to set one up

Conceptually it's three steps:

• pick what to check — a specific saved request, a whole collection, or a branching QA scenario;
• set the interval — 5 minutes or longer, depending on how often you actually need the check;
• point failures (or every run, if that's how you configure it) somewhere — a messenger, a Pushgateway endpoint, or your own webhook URL. All three destinations are supported.

After that, the check lives in the background — the timer fires on its own, without you doing anything.

Where results show up

Every scheduled run lands in the history/event log inside the extension, so this isn't a silent background task whose outcome is invisible. A failed scheduled run shows up in the log as a failure, not nothing. An alert is an additional notification channel on top of that, not the only place you can find out what happened.

An honest limitation: Chrome only

Scheduled Monitoring only works in the Chrome build of PolyApiIDE. The Firefox build does not have this feature, and won't in its current form, because Firefox lacks the persistent background execution context this is built on in Chrome. That's not "coming soon" — it's a current platform limitation, and I'd rather say that plainly than promise a timeline I don't have.

The second thing worth knowing upfront: the check runs inside the Chrome extension itself, which means Chrome needs to be running — even minimized or in the background — for checks to fire. This is not a standalone server-side uptime-monitoring service like Pingdom or UptimeRobot that runs independently of your machine. If Chrome is closed or the computer is off, the check doesn't run. It's a convenience layer — "is my saved request/collection still behaving, and will I know if it isn't" — not infrastructure-grade ops monitoring.

Limits: Free vs paid plans

Free is enough to decide whether you even want this feature before paying for it. If you need to watch several endpoints or scenarios at once, paid plans give you up to ten active checks running in parallel.

What it's actually good for

It's a good fit for a canary check on a staging or internal API you're watching during active development, a scenario that needs to keep passing while you iterate on the backend next to it, or a periodic smoke test for an integration you maintain. It is not a replacement for dedicated ops/SRE monitoring tooling — if you need infrastructure-grade reliability that doesn't depend on your own machine being on, that's a job for a specialized service. Scheduled Monitoring is "automatically check that my saved request still works", not production SLA monitoring.

If you haven't set up the extension yet, start with the quick start. For questions on plan limits and platform support, see the FAQ.