Schedule auto updates for WordPress plugins and themes and stop thinking about Tuesdays

The worst part of managing WordPress at any real scale isn't the updates themselves. It's the remembering. Every Tuesday morning a fresh batch of plugin versions lands, and someone has to notice, log in, push the button, verify nothing broke, and log a ticket. Miss one week and the gap compounds — security patches pile up, feature releases diverge across sites, and by the time you finally sit down to clean up, you're staring at 40 pending updates across 12 sites with no idea which is safe to push first.

Scheduled auto-updates fix the remembering. You configure a cadence once — "weekdays at 02:00 ET" or "Sundays at 06:00 in each client's local time" — and the platform does the Tuesday run without you. This post covers how Manage GPL's scheduling works, the decisions we made to keep it safe, and why we deliberately capped the minimum frequency at once per day.

What a schedule looks like in practice

At managegpl.com, a schedule is four knobs:

• Days of the week — pick any subset of Mon–Sun. "Every day" is common for staging environments; "Wed + Sat" is common for production where you want two bites at a week's worth of updates.
• Hour of day — 0 through 23.
• Timezone — an IANA zone like America/New_York or Asia/Kolkata. If you run client sites across timezones, you can give each site its own window so the run always lands during that client's overnight hours, not yours.
• Scope — update all eligible plugins & themes, or a specific whitelist of slugs (e.g., "only Elementor, Yoast, and WooCommerce").

You can set a global schedule that applies to every connected site, and a per-site override that replaces the global for just one site. Override the global for Acme's production site to run Thursday at 06:00 EST; leave every other site on the default. The mental model is the same one WordPress uses for theme overrides: child beats parent, per-site beats global.

The once-a-day floor, and why we're not budging

Every couple of weeks someone asks us to support sub-daily schedules: "Why can't I run updates every 6 hours?" The answer is that we checked, and nobody actually needs that — they're thinking of it as a convenience knob without considering what it implies for the rest of the stack.

A plugin update, from the connector's perspective, is an HTTPS download of a ~1–10 MB zip, a filesystem extract, an optional schema migration, and an opcache_invalidate. On a small shared-host VPS, that's 10–60 seconds of real CPU. For a user with 100 sites, 4 runs a day means 400 of those operations, most of which will do nothing — because the actual rate of new plugin versions arriving is roughly 2–5 per plugin per month. You're paying for polling you don't need.

A daily schedule catches every plugin release within 24 hours, which is well inside the patch window that matters for security (the bad days for a zero-day are measured in weeks, not hours). If you need immediate patching for a specific high-risk plugin, use the "Update now" button on the site's page — that's the fast lane. The scheduled flow is for the long tail of routine updates.

What runs, what doesn't, and how failures surface

When a scheduled run fires on Manage GPL, the platform:

1. Walks the current inventory on each target site and picks up the items eligible for update (non-paused, non-disabled, version mismatch, package available).
2. Fires a bulk update in chunks of three items at a time through the connector's signed REST endpoint. Same batching behaviour as manual bulk updates — different sites run in parallel, chunks within one site serialise via a per-site lock so the connector never sees overlapping requests.
3. Waits for every chunk to finish, writes an activity-log entry per item, and sends one email summarising the run.

We deliberately don't auto-toggle maintenance mode during a scheduled run. WordPress plugin updates are already atomic at the file level and take seconds; visitors landing on a site during that window almost never notice anything. Wrapping the whole batch in maintenance mode added a class of failure modes where a worker hiccup would leave the site 503-ing until an orphan sweep ran hours later. If you really need a holding page during a specific window, flip Maintenance mode on the site manually before your scheduled hour and off after — it's a one-click button in the site's dashboard.

Failure emails are on by default; success emails are opt-in. Most days you should hear nothing, which is the point. When you do hear from us, it's because something needs human attention, and the email tells you exactly which site, which plugin, and the error message the connector returned.

What we explicitly left out (for now)

• Pre-update backups. We thought about it, but "trigger a backup" means depending on the host's backup tool (UpdraftPlus, managed-WP host snapshots, custom rsync jobs) and every one of those has its own API. Backup-before-update is the right behaviour — just not one we can reliably automate across every WP host. If your host has a snapshot hook, wire it into the site's lifecycle separately.
• Rollback on failure. Related to the above. A failed update leaves the plugin on its old version (that's what the connector's fatal-error drop-in gives you for free); rolling back a successful-but-bad update needs a pre-update snapshot, which we don't own.
• Multiple schedules per site. One schedule per scope. If you want "Yoast daily, everything else weekly," set up a specific-slugs daily for Yoast + a separate weekly global. That's it — no "first Monday of the quarter" cron expressions.

Getting started

Scheduled auto-updates are on the Developer and Agency plans at managegpl.com. If you already have an account, open Settings → Schedule Updates and pick a cadence — it takes under a minute. If you don't, sign up; the Free plan connects five sites so you can see the dashboard before committing.

And then go do something else on Tuesdays.