If an error occurs when processing a scheduled subscription payment, a notice will appear in the admin dashboard to alert store managers of this error.
This guide will explain why this notice is displayed, the likely causes of the issue, steps to diagnose the cause, and how to fix the problem or get help.
Past-due actions refer to tasks that have missed their scheduled dates. It’s worth noting that due to how WP Cron works, it’s not uncommon to have some past-due actions in your system. If you come across multiple past-due actions that are more than a day old, it could indicate a potential issue with WP Cron on the website. This may result in issues related to missing orders, subscriptions, or data within the WooCommerce Analytics.
For a deeper understanding of WP Cron’s role in managing Scheduled Actions, and to troubleshoot issues with WP Cron, we recommend referring to our comprehensive guide on scheduled events for subscriptions.
As mentioned in Action Scheduler housekeeping, if an action has been “running” for more than five minutes, it is considered to have timed out and is marked as failed. This is because if an action has been running for that length of time, it is likely not actually running at all. When a subscription-related action fails due to a timeout, a notice is displayed in the admin dashboard.
The notice that appears after an action timeout contains a note with the subscription number and a link to the edit subscription page for that subscription. This can be used to investigate if there are issues with the last renewal payment for that subscription that need to be manually addressed.
The first step to this is to see if payment was actually affected. This can be done by tracking when the payment process was affected.
Tracking the Renewal Process
For a renewal order, each stage of the renewal process is documented on the subscription in its notes. To view this process:
- Go to the WooCommerce > Subscriptions > Edit Subscription screen
- View the Subscription notes
- When a renewal is due, the subscription is moved to an On-hold status
- An order is created to record the renewal
- If the subscription is on automatic renewals, the order attempts to process payment and may mark complete
- Once payment is complete, the subscription is moved to Active status
Comparisons can be made between the payment process and the failed action in order to find out when the process timed out.
Failure Before Payment
If the renewal order was created but the payment was not marked complete, the process may have stalled before payment was processed. This can be indicated if the time of failure of the action, as found above, is close to the time of the creation of the renewal order.
To make sure that the payment was not captured, there are a couple steps to take.
- Go to the created order, linked to in the Subscription notes
- Check the Order notes on the order to see if the status changed and the payment was processed
If there is no charge, then the processed stalled before payment was taken.
Failure After Payment
If payment was captured but the order was not marked Processing or Complete or the subscription was not transitioned to an Active status, then the process stalled after payment. This can be indicated if the time of failure of the action, as found above, occurs after the payment was marked complete.
Affected Before Payment
If payment was not captured:
- Check if there’s a renewal order (pending or failed) present for the affected subscription. If yes, change its status to Cancelled and Update. (Note: Please ensure you are only canceling the renewal order, not the entire subscription. Canceling a subscription will prevent it from being switched to active later.)
- Set the subscription status to Active and Update.
- Choose Process renewal from the subscription option dropdown.
- This will then create a new renewal order, which should process as normal.
Affected After Payment
If payment was captured but the order and subscription were not updated:
- If the renewal order was not marked Processing or Complete, change the status to the appropriate status. This will also update the subscription to Active.
- If only the subscription was not transitioned, set the subscription status to Active.
It’s impossible to programmatically identify the cause of a timeout. Instead, they always require manual investigation, which is why this notice is displayed. There are a number of possible causes, as outlined below, which should be explored to find the cause of the timeout.
These timeouts, and thus the error notices, are expected to be extremely rare occurrences with Subscriptions 2.4.3 or newer.
If this notice appears on a site running a version of Subscriptions less than 2.4.3, the first step is to update the Subscriptions version.
If a site is currently running a Subscriptions version greater than or equal to 2.4.3, the version of Subscriptions at the time of the error should be checked. Even if Subscriptions has since been updated, it is important to note what version was running at the time the notice first appeared.
In order to check the version of Subscriptions running when the error occurred:
- Review the WCS Upgrade log and the Failed Scheduled Actions log
- Compare the time the error is logged in the Failed Scheduled Actions log to the version running at that time, as found in the WCS Upgrade log
If a Subscriptions version less than 2.4.3 was running at the time of the error and Subscriptions has since been updated, the underlying issue has likely been resolved.
If the version of Subscriptions was newer than that at the time of the error, further investigation is needed.
The PHP time limit is the amount of time the server will spend on a single process before timing out. A time limit that is too short can cause processes to time out. A common default value is 30 seconds, and many managed hosts provide a longer timeout period.
To find the PHP time limit for your server:
- Go to WooCommerce > Status to view the system status
- Scroll down to the Server environment section
- View the PHP time limit
If this limit is below 30 seconds, we recommend increasing it to avoid scheduled action timeouts.
To change this limit, contact your hosting provider and discuss with them the best way to change the time limit if possible.
This kind of notice and timeout is expected to be a very infrequent occurrence, and certainly not something that occurs repeatedly. In sites where there are dozens of timeouts or more, there is likely a critical underlying problem causing the timeouts that will need to be addressed.
To check the number of timeouts review the Failed Scheduled Actions log.
If there are many timeouts, please open a support ticket.
Fatal errors that are triggered in the code by a PHP function can contribute to failed scheduled actions. To look for fatal errors, see WooCommerce Fatal Errors Log.
If you would like further assistance, please open a support ticket.
In the support ticket, please include the system status, so we can find your site’s PHP time limit and plugin versions, and the name of your host, so we can investigate their specific server limitations. If in Step 1 you were able to determine the active version of Subscriptions at the time of the error, include this as well.