Subscriptions System Status Report

The WooCommerce Subscriptions system status report can be found in the WooCommerce > Status section of your site. This information is gathered from your site and is stored locally on your site. When submitting a support request, the system status report plays a vital role in the initial diagnosis of possible issues.

Displays whether the WCS_DEBUG constant has been enabled.

Enabling the WCS_DEBUG constant allows some additional information to be logged and displayed, which can help during troubleshooting.

WCS_DEBUG is not enabled by default, but can be enabled by pasting the following snippet into your wp-config.php file:

// Enable WP_DEBUG mode  
define('WP_DEBUG', true);
if ( ! defined( 'WCS_DEBUG' ) ) {
   define( 'WCS_DEBUG', true );
}

Displays whether the Subscriptions plugin is in either Live Mode or Staging Mode.

Subscriptions will keep a record of the URL of the site where it is first activated. It considers this to be the live site and will run in live mode. If the site’s URL then changes, it considers the new site to be a staging site and it will run in staging mode.

Check out How Subscriptions Handles Staging Sites for more information on Subscriptions Live Mode and Staging Mode.

Displays the Live URL that Subscriptions currently has stored in the site’s WordPress database. This is the URL Subscriptions considers to be the live site and corresponds to where Subscriptions was first activated. How the live site differs from a staging site can be found on How Subscriptions Handles Staging Sites.

This section lists any known Subscriptions template overrides in your theme’s folder. This section will only list the templates that are related to Subscriptions.

This section displays the current number of subscriptions of each status in the store.

Statuses include: Pending, Active, On Hold, Pending Cancellation, Cancelled, and Expired.

In order to receive updates directly in your WordPress plugins dashboard, an active WooCommerce account must be connected to your site along with an active license for WooCommerce Subscriptions.

The purpose of this section is to show whether or not a WooCommerce account is connected to the site, which is a requirement for receiving updates and support from within your dashboard. If no account is connected, updates will not show up in your plugins dashboard, making it more difficult to install necessary bug fixes and new features on your site.

If the site is not connected to WooCommerce.com, follow this guide on connecting your site to WooCommerce.com.

Several of the rows mentioned below, including Custom Retry Rules, Custom Retry Rule Class, Custom Raw Retry Rule, Custom Retry Rule, and Retries Migration Status, will only display in your status report if automatic retries of failed payments are enabled in your Subscriptions settings. (WooCommerce > Settings > Subscriptions > Retry Failed Payments).

This section will display whether custom retry rules have been set up for the site.

The retry system is made up of a number of different components, each of which implements a distinct aspect of the retry system.

More information on custom retry rules can be found in the Developer Guide to Failed Recurring Payment Retry System documentation.

A specific example of what a custom retry rule may look like can be found in the Example Custom Default Rules section of the custom retry rule documentation.

This will display whether a custom retry rule class has been defined within the site.

More information, as well as an example, of custom retry rule classes can be found in the Rule Class Data Structure section of the custom retry rule documentation.

This section will display whether a custom raw retry rule has been defined for the site.

A raw retry rule is an array. This is the form used to store the default rule set in the protected WCS_Retry_Rules->default_retry_rules property and to store the rule applied for a specific retry in the database.

More information on custom raw retry rules can be found in the Raw Rule Data Structure section. An example of a custom raw retry rule can also be seen in the Example Custom Individual Raw Rule section of the custom retry rule documentation. 

This section will display whether or not there is a single custom retry rule being defined on the site.

You may wish to apply different retry rules for different products, billing schedules, payment amounts or other conditions. To do this, you can customize a specific retry rule based on the order ID and its position in the retry queue.

More information on single custom retry rules can be found in the Custom Individual Rule section. An example of what a single custom retry rule may look like can also be seen in the Example Custom Individual Rule Object section of the custom retry rule documentation. 

This section displays whether the site’s retries migration from wp_posts and wp_postmeta to wp_wcs_payment_retries has been completed after upgrading to version 2.4 of Subscriptions.

To improve the performance of the retry system, Subscriptions made the transition from wp_posts and wp_postmeta to wp_wcs_payment_retries in version 2.4. A custom table, such as wp_wcs_payment_retries, makes the process of retries much more efficient.

For more information on the retries migration process, you can view the Retry Migration to Custom Table section in the retry rule documentation.

This section will display whether the report cache is currently enabled or disabled on the site. Report caching is enabled by default, but can be disabled for larger sites. This is only necessary for larger sites that begin to see issues with the report caching process. Report cache updates will also be disabled on sites where the cache updates have failed more than twice.

Further information on report caching can be found under “How is report data cached?” in the reports documentation.

Disabling report cache for sites with over 100,000 rows in the wp_post table may be a good idea for site performance. Disabling the reports caching can be done by following the “How can I disable report cache updates?” in the reports documentation.

This row will display whether there has been a failure in an update to the reports cache.

On small sites with less than 3,000 subscriptions and 25,000 orders, the process to update the cache for report data is scheduled to be 5 minutes after any event that would invalidate the existing cache.

On sites with more than 3,000 subscriptions or 25,000 orders, the cache is only updated once per day. This update begins at 4 am in your site’s timezone.

If you begin to see errors with report cache updates, it may be a good idea to reach out to WooCommerce Subscriptions support, which you can do by opening a support ticket.