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.