Scheduled Tasks for 3CX: One Calendar for Every Change Across Your Fleet

TL;DR

Nobody can answer "what's about to change on our fleet?": Updates are scheduled in the Update Manager, backups recur on per-instance intervals, and restore tests rotate on their own clock. With the schedule scattered across screens, a maintenance window collides with a backup — or a customer's phones restart mid-shift — because no one had the full picture.
Scheduled Jobs rolls all of it into one timeline: Sikurd's Scheduled Jobs view gathers every upcoming change across the fleet — scheduled 3CX updates, one-off and recurring managed backups, and rotating restore-verification tests — into five time buckets: Due now, Next 24 hours, Next 7 days, Later, and No set time.
Read-only by design — one calendar you can trust: It's a rollup, not a cron builder. You schedule the actual work in each feature area; this view just shows it. The single action here is cancelling a scheduled update. The payoff is cleaner change windows and no surprises.

The real question: what's about to change across the fleet?

If you manage a fleet of 3CX servers, scheduled change is happening constantly — and it's happening in pieces. You queue a round of updates for tonight's maintenance window in one screen. Each instance is taking recurring managed backups on its own interval, set when you enrolled it. And in the background, Sikurd is rotating through your instances running restore-verification tests so you know the backups actually restore. All of that is good. The problem is that it lives in three different places, on three different clocks.

So when someone asks the question that actually matters — “what’s about to change on our fleet, and when?”— there’s no single screen that answers it. You’d have to open the Update Manager to see queued patches, check each instance’s backup settings to work out when the next capture lands, and remember where each box sits in the restore-test rotation. Nobody does that across twenty or fifty PBXs. So the schedule effectively lives in people’s heads, which is exactly where collisions come from.

The failure modes are mundane but expensive. A scheduled update fires at the same time a long managed backup is mid-capture. A customer’s phones restart during business hours because the maintenance window in one tech’s calendar didn’t match the one actually queued. A restore test runs on the same night you planned a big patch rollout, and now you’re reading two sets of logs instead of one. None of these are mysteries after the fact — they were all on a schedule. They just weren’t on the same schedule, where a human could see them about to overlap.

The fix isn’t another scheduler. It’s one place that shows you everything already scheduled, on a single timeline, so the overlaps are obvious before they happen.

The unified view: Scheduled Jobs

Sikurd’s Scheduled Jobsview is a tenant-wide, read-only rollup of upcoming scheduled work across your whole fleet. It reaches into every feature that schedules something, pulls out what’s coming, computes when each item will next run, and lays it all out on one screen. Instead of assembling the change calendar in your head, you open one page and the entire estate’s upcoming changes are in front of you.

What it rolls up:

Scheduled 3CX updates — patches you’ve queued for a specific time, each shown with its instance, the number of updates to install, and whether a fresh backup is taken first. These are the only items with a cancel action.
One-off “back up now” requests — when you’ve asked an instance to capture a managed backup on demand, it appears here as queued so you can see it’s in flight.
Recurring managed backups — for every instance enrolled in managed/verified backups, the next scheduled capture, derived from its interval (every N hours) and its last capture.
Rotating restore-verification tests — the next time each enrolled instance is due for a real restore test, derived from its last passing restore and the rotation window (roughly every 30 days).

Each row tells you the same few things at a glance: the type (update, backup, or restore test, with recurring items flagged), the instance (a link straight to that PBX), the time in your tenant timezone, and a short detail— “backup first,” “every 6h,” “every 30d,” “queued now,” or “awaiting first capture.” You can filter by type with a click, so “show me only the updates coming up” or “just the restore tests this week” is one tap.

The five time buckets

Everything is grouped into time buckets, computed server-side at the moment you load the page, so the grouping is stable and honest. They map to the only horizons you actually plan against:

Due now
Anything at or past its scheduled time — the things to look at first.
Next 24 hours
What's landing today and tonight, including the maintenance window you're about to run.
Next 7 days
The week ahead — the planning horizon for staggering work across customers.
Later
Scheduled, but further out. Visible, so nothing is a surprise when it arrives.
No set time
Items without a concrete moment yet — e.g. a recurring backup on an instance that hasn't captured its first one, shown as "awaiting first capture" rather than a guessed date.

Within each bucket, items are sorted by time, soonest first. The result reads like a change calendar: glance at “Next 24 hours” and you immediately see whether tonight’s update collides with a scheduled backup, or whether a restore test is about to run on the same box you planned to patch.

What you can schedule, and where you schedule it

This is the important distinction, because Scheduled Jobs deliberately doesn’t createanything. It’s a window onto schedules that are set in each feature’s own screen. Here’s where each kind of change actually gets its time:

Updates — a real date-and-time picker, plus backup-first. When you queue a 3CX update in the Update Manager, you choose “update now” or “schedule for” a specific moment, and toggle whether a fresh managed backup is taken before installing. Each instance becomes its own job at its own time. Those scheduled jobs are what surface in the rollup. (For the full mechanics of safe, backup-protected patching at fleet scale, see Scheduled, backup-protected 3CX updates.)
Managed backups — a recurring interval. Enrol an instance in Verified / Managed Backups and set how often it captures — every N hours. The view reads that interval and the last capture to show the next occurrence. (What “managed backup” really means, and how Sikurd proves they restore, is covered in Verified Backups.)
Restore-verification tests — a rotation.You don’t schedule these by hand; Sikurd rotates through enrolled instances on roughly a 30-day cadence, taking a real backup and restoring it onto a sealed-off server to prove it works. The rollup shows when each instance is next due.

So the mental model is clean: configure the schedule where the feature lives; read the schedule, all of it, in one place.Nothing about Scheduled Jobs lets you invent arbitrary recurring jobs or write a cron expression — and that’s the point. It’s a trustworthy calendar precisely because it only ever reflects what’s really configured.

Read-only by design (with exactly one exception)

A rollup that also lets you edit everything becomes another control surface that can drift out of sync with reality — which defeats the purpose. So Scheduled Jobs is read-only, with a single, carefully chosen exception: you can cancel a scheduled updatebefore it runs. That’s the one moment where seeing the calendar and acting on it belong together — you spot that tonight’s patch on a particular customer is bad timing, and you call it off right there, without hunting back through the Update Manager. (Cancel is gated to the roles that can manage updates.)

Everything else routes you back to the right screen. Want to change a backup interval? That’s a backup setting. Reschedule an update for a different night? That’s the Update Manager. The rotation cadence for restore tests is managed by Sikurd. Keeping the rollup honest means it’s the calendar everyone can trust, not a place where the schedule quietly forks from what’s configured.

Why one change calendar beats five screens

The build-it-yourself alternative is the status quo: keep the update schedule in one tool, the backup cadence in per-instance settings, the restore rotation in your memory, and reconcile them by hand whenever you plan a window. Across one or two PBXs that’s fine. Across a real fleet it produces the collisions everyone’s seen — the overlapping jobs, the off-hours restart that wasn’t supposed to be off-hours, the “wait, that box was being restore-tested tonight?”

A single time-bucketed view closes that gap. You see every upcoming change across the fleet in one place, grouped by how soon it matters, with the soonest things first. Maintenance windows get cleaner because you can see what else is already booked for that window. Surprises drop because “Later” is still visible long before it becomes “Due now.” And it’s all without logging into a single 3CX console — the same one-pane principle that makes the rest of fleet management tractable.

Adjacent reading

Scheduled, backup-protected 3CX updates — how the updates that show up on this calendar are queued, backed up first, and run safely at fleet scale.
Verified Backups — what the recurring backups and rotating restore tests in this view actually are, and how Sikurd proves a 3CX backup restores.
Best tools for managing multiple 3CX servers — the broader one-pane fleet-management picture.

Frequently asked questions

Is this a cron scheduler — can I create my own recurring tasks here?

No, and that's deliberate. Scheduled Jobs is a read-only rollup, not a build-your-own task scheduler. It doesn't accept cron expressions or arbitrary custom jobs. It shows the scheduled work that already exists across your fleet — 3CX updates you queued, the recurring managed backups your instances are enrolled in, and the rotating restore-verification tests — all on one timeline. You schedule the actual work in each feature area; this view just gathers it into one place so you can see what's coming. The only action you can take from the view itself is cancelling a scheduled update.

What can I actually change from the Scheduled Jobs view?

Exactly one thing: you can cancel a scheduled 3CX update before it runs (and only if you have the right role — Owner or Super Admin). Everything else is informational. To change a backup interval, a restore-test rotation, or the time of an update, you go to that feature's own screen. Keeping the rollup read-only is intentional — it's a calendar you trust to tell you the truth, not another place where settings quietly diverge from reality.

Where do I set the times that show up here?

In each feature area. Scheduled updates get a real date-and-time picker (plus a backup-first toggle) in the Update Manager when you queue a push. Managed backups run on a recurring interval — every N hours — set per instance when you enrol it in Verified / Managed Backups. Restore-verification tests run automatically on a rotation (roughly every 30 days per instance). The Scheduled Jobs view reads all of those and computes the next occurrence for each, so you never have to assemble the schedule by hand.

Why do some rows show an exact time and others don't?

Scheduled updates and one-off "back up now" requests have a specific moment attached, so they show their exact time in your tenant timezone. Recurring managed backups and restore-verification tests are interval- or rotation-based, so the view shows the computed next occurrence. If an instance hasn't captured its first backup yet, there's no anchor to compute from — that item lands in the "No set time" bucket labelled "awaiting first capture" rather than guessing a date.

What do the time buckets mean?

Everything is grouped into five buckets relative to right now: Due now (anything at or past its time), Next 24 hours, Next 7 days, Later, and No set time. The buckets are computed server-side at request time, so the grouping is stable and accurate for the moment you loaded the page. They exist to answer the only question that matters at a glance — is something about to happen on this fleet in the next day, the next week, or further out?

Does this replace the per-feature screens for updates and backups?

No — it sits on top of them. The Update Manager is still where you scan, select, and schedule patches; the backup settings are still where you set an instance's interval; restore-verification still runs on its own rotation. Scheduled Jobs is the consolidated change calendar across all of them. Think of it as the answer to "what's about to change across the whole fleet, and when?" without opening five different screens or logging into a single 3CX console.

Do I have to pay for this, or is it gated to a tier?

There are no tiers and no feature gating in Sikurd — every feature is included for every account, and you're billed per instance beyond the first three. Scheduled Jobs comes with the platform. Your first three instances are free, forever, so you can connect a few PBXs and see the unified change calendar without a card.