Introducing Scheduled Jobs: Run Jobs on Your Joomla and WordPress Sites, and Know When They Fail

Most agencies have a client site with a URL that has to be called on a schedule. A shop pulls in its stock feed every hour, and the thing calling that address is one line in a crontab on a server you forgot about. When that server is switched off, or the address starts answering with an error, the feed stops and no one is told.

mySites.guru now has Scheduled Jobs. A scheduled job runs something on a schedule for one of your connected Joomla or WordPress sites, starting with a ping to a URL on the site, and tells you when it starts failing. The 45-second film below shows it.

There are more short films like this on the films page.

Set Up a Ping a URL Job

Ping a URL is the job type every site gets, whether it is Joomla, WordPress or Generic. Open the Scheduled Jobs page, or find it through Cmd+K or the s j hotkey, and work down the editor.

1. 1

   Name the job. Give it a name you will recognise in an alert email.

2. 2

   Pick the site. Choose one of your connected sites.

   One save can create the same job on up to 100 sites. You enter a path, so each call goes to its own site.

3. 3

   Choose Ping a URL. Pick the method: GET, HEAD or POST.

   You can save up to 10 request headers and basic auth. They are stored encrypted and never shown back in full.

4. 4

   Enter the address. It has to be on the site's own domain.

   Expect status sets the reply status that counts as working. You can also check the text of the reply.

5. 5

   Pick how often. Choose a preset under Every, write a Cron expression, or pick Once.

   One live sentence says what the job will do and when, and Next runs lists the next five.

6. 6

   Press Test. Test tries the job once without saving it.

   A test does not count as a run.

7. 7

   Save the job. From here it runs on its schedule, and Run now runs it once straight away as a real run.

   Run now and Test together are limited to 10 an hour per person.

Each call has a 10 second connect timeout and 30 seconds in total. It reads at most 64 KB of the reply and follows up to 3 redirects. The request goes out from mySites.guru’s fixed outbound address, the same one you already allowlist for your sites.

Once saved, each job shows its last 30 runs at a glance, and run history is kept for 90 days. A site’s Manage Site page has a Scheduled Jobs pane for that one site. On the main page, e edits the selected row, Shift+R runs it and Shift+P pauses or resumes it. You can pause a job, or pause it until a date, and resume it later.

Why Can a Job Only Call Its Own Site?

A Ping a URL job may only call the connected site it belongs to: the site’s exact host, its www twin, or a subdomain. The site has to be connected, and the rule is checked when you save, when you press Test, on every run and on every redirect.

That was my choice, and I would make it again. A service that will call any address you type on a timer is a tool for making our servers hit someone else’s server. mySites.guru only calls sites you have proved are yours by connecting them. The same thinking is behind the smaller rules: only ports 80 and 443 are allowed, and a hostname that resolves to a private address is refused.

The saved credentials stay private on the page too. It shows header names only, and shows basic auth as set or not set.

One Alert Per Outage, and One When It Recovers

Alerting on every failed run is how people learn to ignore alerts. Scheduled Jobs sends one alert after a number of failures in a row that you choose. The setting is Alert after N failures in a row, from 1 to 10, and the default is 2. A long outage is one email, and when the job works again you get one recovery message.

A failed GET or a connection failure is retried once, a minute later. If a job reaches 20 failures in a row it pauses itself and sends one more message.

Alerts go by Email, Web push or Webhook. The webhook can be Slack-compatible, Discord, Microsoft Teams or signed JSON, set up once under your webhook settings, with Scheduled Jobs alerts as a family you opt in to. The post on uptime alert webhooks covers setting up a webhook. Email and push stop at 10 an hour per person, and anything over that is counted in the next email. Failing jobs also show in the left menu under Needs Attention, as Failing Jobs.

Not every run that goes wrong is a failure, and only failed counts towards an alert. The five outcomes are ok, failed, skipped, unknown and lost. Skipped covers things like a paused or disconnected site, or a last run that was still going. Unknown means no reply came back, so the job may have run. A POST or CMS job that times out is recorded as unknown, because calling it failed would be a guess.

This sits beside uptime monitoring and answers a different question. Uptime tells you the site is up. A scheduled job tells you the thing the site is meant to do happened.

Send Downtime Alerts to Teams, Google Chat, Discord or Your Own CodeWhen the mySites.guru uptime monitor finds one of your connected sites down, the alert can now go to Slack, Discord, Teams, Google Chat or signed JSON webhooks.Read the full post

Replacing WP-Cron on a WordPress Site

WP-Cron is triggered by page loads. The WordPress Plugin Handbook explains the result: on a quiet site, scheduled events run late or not at all. It also says the page-load trigger can be disabled in wp-config.php once a real scheduler calls WP-Cron, and that running it on every page load after that adds needless load.

A Run WP-Cron job is that real scheduler. It runs the WP-Cron events that are due, the way WordPress would on a page load. The Replace WP-Cron wizard on a WordPress site adds the job and then, behind an explicit tick, turns off the page-load trigger by writing this line to wp-config.php:

define('DISABLE_WP_CRON', true);

There is an Undo. If the trigger is already off, the wizard offers to turn it back on, and deleting the last such job warns you so you can switch the page-load trigger back on. A site with the trigger off and no job calling it would run no scheduled events at all, which is why the warning is there.

WordPress has two more job types. One WP-Cron hook runs a single event picked from the site’s own list. It can only run an event the site’s connector listed itself, and the connector refuses to run an event it flags as looking hacked. WordPress REST calls a REST route inside the site, GET only, with no HTTP round trip.

Running Joomla Scheduled Tasks Without a Server Cron

Joomla’s default scheduler has the same weakness as WP-Cron. The Joomla guide on how to choose a scheduler describes the Lazy scheduler as running due tasks during visits, so nothing runs on a quiet site. The alternatives ask more of you: Web Cron needs a cron job somewhere calling a secret Webcron link, and CLI needs server access.

A Run a Joomla task job runs one Joomla scheduled task through Joomla’s own scheduler, on Joomla 4.1 and later. Joomla 3 sites and Joomla sites before 4.1 get Ping a URL only.

A task that still does not run may be stuck. A stuck lock is why a Joomla task stops running, and mySites.guru can detect locked Joomla scheduled tasks for you.

The site’s connector updates itself. Until it does, WP-Cron and Joomla task jobs on that site are recorded as skipped, with the message “The site’s connector is out of date. It updates itself”, and never as failures.

Detect Locked Joomla Scheduled Tasks Before They Cause ProblemsJoomla's Task Scheduler can leave tasks stuck in a locked state after crashes or timeouts. mySites.guru detects and unlocks them across all your sites.Read the full post

The Five Job Types

What Happens to a Missed Run?

A missed run is skipped. A due time more than 15 minutes old is not run late, so after an outage you get one run and the job goes back on its schedule. A queue of late runs firing one after another at a site that has only just recovered is the last thing it needs.

Schedules come in three forms:

• Every, with presets of 5, 10, 15 and 30 minutes, 1, 2, 6 and 12 hours, daily at a time, or weekly on a day at a time
• Cron, a five-field cron expression
• Once, a date and time

All three are read in the job’s own timezone. The shortest gap is 5 minutes, so an every-minute cron is refused. Each job also gets its own minute offset, so jobs on the same preset do not all fire at the same second. If you put an hourly job on every WordPress site you manage, they will not all start together.

Jobs run only while the account has an active subscription. A lapsed account’s jobs wait, and resume from the next slot when it is active again, with no catch-up. An account can have up to 100 active jobs.

mySites.guru already schedules your audits, updates and backups. Scheduled Jobs covers the work that is particular to one client’s site.

API, MCP and Team Permissions

Scheduled Jobs is in the mySites.guru API at /api/v1/scheduled-jobs, with the scopes api:scheduledjobs:read and api:scheduledjobs:write.

The MCP server has six tools for it: list_scheduled_jobs, get_scheduled_job, save_scheduled_job, delete_scheduled_job, pause_scheduled_job and run_scheduled_job.

For team members, there is a Scheduled Jobs permission on the team member’s permissions, set to View or Manage. A junior who should see that the stock feed ran, and not be able to change where it points, gets View.

If a URL on a client’s Joomla or WordPress site has to be called on a schedule, move it out of the forgotten crontab and into Scheduled Jobs, where a failure reaches you before the client notices.