Stop the hosting cron job for an old WordPress site

Define the old process to stop

After a migration, a hosting scheduler may still call the previous WordPress installation. A PHP command may point to an old folder, while an HTTP command using the public domain may now reach the new site. In the latter case, the old hosting account can trigger tasks on the current site. Before removing a line, identify the actual target, the process owner, and where triggering must be retained.

Record the symptom prompting the intervention. This could be an access log on the old server, repeated sending, or a billed task that should no longer exist. A log time repeating at an interval is a clue. Match it to the scheduler configuration and its time zone. A manually started process may also produce a similar entry. Keep the observations before changing anything.

The removal here concerns the system launcher or external call. Events stored in WordPress and application tasks must be handled separately if their deletion is planned. A migration may require these events to remain on the new site, with a single mechanism responsible for triggering them.

Read the command and frequency in cPanel

Open Advanced, Cron Jobs, then the existing task list. Record the entire command, interval, and notification settings. If the provider uses another interface, request the same information for the hosting account concerned. Copy these details only into the private maintenance record. A trigger URL or command may contain a secret, an identifier, or an internal path. Support can receive a redacted version.

Distinguish a command that directly executes a PHP file from one that calls a URL. Record the binary, script path, options, any working directory, and output redirections. An intermediate script may choose the site itself or run several processes. Open an authorized copy to determine this logic without executing it. If a command is too complex or its origin remains unknown, involve its owner.

An empty email setting or output redirected to a sink may suppress notifications without stopping the task. The end of emails therefore does not demonstrate the end of triggering. The record must retain the command and schedule, not just the address that received its messages.

Confirm the target of an HTTP call

For a command that contacts the public domain, ask where that name resolves from the old hosting account and whether it follows redirects. The server’s DNS may differ from your workstation’s. A local resolution file or client configuration may also force an address. Avoid running the complete command to discover its destination if it triggers writes, messages, or a business task.

Compare the name, client options, and existing access logs. If you see a regular call to wp-cron.php on the new server, investigate whether its origin matches the old scheduler. A shared address may require provider confirmation. If the name redirects, determine the destination without calling the sensitive action, using read-only tools and traces already available.

The owner must confirm whether this launcher is still the official production mechanism. It may have been retained temporarily during migration to keep tasks running regularly. Removing it before its replacement is in place may leave the public site without the expected trigger. Record the replacement mechanism’s state and evidence that it works before deleting the old line.

Confirm the target of a PHP or WP-CLI launch

For a local command, identify the resolved script path and the WordPress root it loads. A symbolic link to the current folder may point to a different package from the one its name suggests. A custom script may include wp-load.php from a calculated location. Ask for the deployment reference and expected database to confirm the target through an independent source. A folder named old does not prove that it is out of service.

Check the system account and PHP used by the scheduler. They may differ from the context of your SSH session. A command that works in an interactive terminal may receive different variables or permissions in cron. Record the configuration and existing execution logs before proposing a correction. Read access is often enough to identify the target without running the process.

If the old folder still uses the current database, do not conclude that the process has no effect on production. Have the owner confirm this shared use. The first decision may be to separate access or move the process to the correct service, with a plan to stop the old launcher.

Observe events on the authorized target

Once the root and loaded code have been recognized as authorized, WP-CLI can list the site’s scheduled events. The example below lists their names and their next relative run times. It does not request event execution. Replace the path with that of the confirmed target and keep the inventory in the private area. Initializing WordPress loads its code, which warrants a static approach if the old copy is suspicious or must no longer start.

Compare the list with known business functions. Publishing, sending, or maintenance events may still be needed on the new site. Their presence in the old database indicates potential work, without proving that a launcher still processes them. Compare the inventory with the existing log and scheduler state. Avoid running all overdue events to test the hypothesis.

On the current site, confirm which mechanism is supposed to trigger WP-Cron and whether DISABLE_WP_CRON has been defined in its configuration. This constant prevents the usual visit-related trigger, but does not prove that external calls or system tasks have disappeared. Check the launcher configuration separately.

wp --path=/chemin/vers/wordpress cron event list --fields=hook,next_run_relative,recurrence

Prepare the shutdown with the state of ongoing processes

Keep the exact command and schedule in the private record, along with their owner. Ask the provider whether the interface offers a documented suspension or only deletion. Prepare a way to restore the line if a legitimate dependency has been overlooked. The configuration copy must preserve the arguments and context while keeping secrets in the vault. A public screenshot is unsuitable for this backup.

Check whether a process started by this line is still active. Removing the next trigger does not necessarily terminate a process that has already started. If a process is running, record its reference and ask its owner for a safe stopping point or confirmation that it has finished. Avoid arbitrarily interrupting a process that may write data, send a batch, or hold a lock.

Also confirm the takeover by the correct service. If the old launcher performed necessary work, the replacement must have produced the expected evidence before final shutdown. For a write process, identify the last successful batch and how to avoid a duplicate restart. Record the conditions that would trigger a rollback.

Remove only the trigger that is no longer needed

In the hosting interface, select the identified entry and apply the intended suspension or deletion action. cPanel documents a Delete action on the relevant line, followed by confirmation. Check the displayed command before confirming, especially if several lines use the same domain with different arguments. One entry may call a backup and another the WordPress engine. Removal must remain tied to the validated use.

If the scheduler is generated from a repository or server configuration, have that source corrected. A local deletion may be reversed on the next deployment. Ask for the published configuration version identifier and check the resulting list. In a server fleet, each instance may have its own line. The check must cover the locations that can trigger the process, according to the inventory.

Leave useful WordPress events in place on the destination site. Deleting a launcher does not imply clearing the application queue. If an old copy must be removed entirely, prepare that separate operation after checking its data, access, and remaining uses.

In cPanel, the Current Cron Jobs table lets you identify the line to remove. The documented workflow uses Delete on that line, followed by a second Delete confirmation. Keep the five scheduling fields and the entire command before confirming. For an authorized restoration, Add New Cron Job lets you restore these exact values; the Common Settings presets do not replace the saved frequency. Compare the scheduler’s time zone with the logs’ time zone before choosing the next observation window.

Check for the absence of a new start at the right time

Wait for a time when the line should have triggered, then check the scheduler list and designated logs. Record the check time, time zone, and period covered. A five-minute interval can be checked quickly, while a monthly task requires other evidence. The provider can confirm that the line no longer exists in the published source. Distinguish this configuration confirmation from observation over an entire execution period.

Also check that previously started processes have ended when stopping them was part of the plan. The absence of a new start does not prove that the last process has finished. Ask for a completion reference or a business state confirmed by its owner. If an old HTTP call continues, look for another scheduler or external service using the same URL before changing the destination WordPress installation.

On the current site, observe the next expected work. For example, check a demonstration event or a scheduled maintenance log that does not cause an unauthorized external action. The evidence must confirm that the necessary mechanism remains operational after removal of the old launcher.

Handle duplicates discovered during observation

A migration may leave two apparently legitimate mechanisms, such as a cPanel scheduler and an external monitoring service. Compare their schedules, destinations, and owners. Identify which should remain in charge of triggering. Multiple calls to wp-cron.php do not necessarily mean that each event runs twice, because WordPress has its own coordination mechanisms. However, custom scripts or business tasks may follow other rules.

If you observe a repeated business operation, record the batch identifiers and the result actually produced. A duplicate notification, duplicate write, or increase in request count requires different checks. Avoid replaying processes before reconciling the current state. Removing the launcher corrects future starts but does not automatically repair data already changed.

For a line that reappears after deletion, check configuration management and the owning account. A hosting service may recreate a task required for its offering. Have its role confirmed and request a correction at the responsible level, with a record specifying the expected site and destination.

Roll back without restarting an unknown batch

If a useful service stops after removal, first identify the task and its last confirmed result. Restore the previous line only if the rollback plan allows it and its target remains correct. An HTTP command may point to another destination since the DNS change. Blindly restoring the old line may therefore trigger the process on the wrong WordPress installation. Review the context and arguments before enabling it.

For a suspended task that accumulates items, ask the owner how to resume the queue. Restoring the schedule may cause a large backlog to be processed quickly. Check rate limits and effects on external services according to the mechanism used. Do not combine this rollback with a manual run of the same batch without coordination.

If the problem comes from another change, such as a new PHP version or a missing variable, have that cause addressed. Reactivating the legacy launcher does not prove that it is the right long-term architecture. After rollback, confirm the business result and record the next decision so a temporary mechanism does not become permanent without an owner.

Document the retirement of the old launcher

The final handover should include the hosting account, redacted command, its full private reference, the confirmed target, and the replacement mechanism. Add the removal time, the state of the last process, and the period observed without a new start. If you could not examine a process or an infrequent task, assign that check to its owner. The next maintainer must be able to understand which part was stopped and which function is still expected on the current site.

Task interfaces and shell access depend on the hosting plan. WordPress inventory commands use WP-CLI when available. The method requires no additional plugin or purchase when this access is already provided. If the provider manages the tasks, ask for the scope of its intervention and the configuration evidence it can supply.

Finally, add launcher checks to migration acceptance. A record of the source and destination schedulers, together with application queues, helps you decide earlier which server should still perform work.

The WordPress Workshop.

Decode two old commands without running them

Two fictional lines show why the host’s name is not enough to identify the target. A command such as /usr/bin/php /home/compte/ancien/wp-cron.php loads a local file: you must check the actual path and that folder’s database configuration. A command such as curl https://www.example.test/wp-cron.php contacts a network address: after DNS migration, it may reach the new site while remaining registered in the old cPanel account. Do not run either command simply to identify it: both may trigger work.

In Current Cron Jobs, record the five fields and the exact command, then match their schedule against the logs already available. For example, */10 in Minute and * in the other fields means a run every ten minutes according to the scheduler’s clock. A line with minute 15 and hour 3 means 03:15, not an interval of three hours and fifteen minutes.

Before Delete, confirm which launcher remains responsible on the new hosting account. After deletion, observe the next scheduled time in the destination logs. Disabling email notification does not remove the task, and the line disappearing does not terminate a process that is already active. Keep these two checks separate in the handover.