Site Health Check changes in 5.6

With the release of WordPress 5.6, enhancements have been made to the way the Site Health component handles, and validates, health checks.

Site Health check data validation

First up is #50145. It adds validation rules to the response form for an asynchronous site-health check.

Prior to this patchpatch A special text file that describes changes to code, by identifying the files and lines which are added, removed, and altered. It may also be referred to as a diff. A patch can be applied to a codebase for testing., any invalidinvalid A resolution on the bug tracker (and generally common in software development, sometimes also notabug) that indicates the ticket is not a bug, is a support request, or is generally invalid. asynchronous response would cause a fatal JavaScriptJavaScript JavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a user’s browser. error, halting further processing of checks, and preventing the top of the page indicator from ever reaching a finished state.

An invalid response will now just be discarded with the introduction of this data format validator. It will not count towards the Site Health indicator or be listed among the checks.

(Oh, and you’re no longer required to add a badge to your checks. It’s useful, but not a hard requirement).

Asynchronous health checks via REST endpoints

With ticketticket Created for both bug reports and feature development on the bug tracker. #48105, we see Site Health moving away from admin-ajax.php for its asynchronous tests towards a dedicated REST APIREST API The REST API is an acronym for the RESTful Application Program Interface (API) that uses HTTP requests to GET, PUT, POST and DELETE data. It is how the front end of an application (think “phone app” or “website”) can communicate with the data store (think “database” or “file system”) endpoint.

Starting in WordPress 5.6, asynchronous tests can be found under the /wp-json/wp-site-health/v1 namespace.

This also opens it up for plugins and themes to utilize REST endpoints, and not just ajax actions, for their tests. To maintain backwards compatibility, each test can now declare has_rest (defaults to false). If this is of a true value, then the test argument is treated as an absolute URLURL A specific web address of a website or web page on the Internet, such as a website’s URL (this means that it should be a fully qualified address, and not a relative one), for example, by using the rest_url() function provided by coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress..

The reason for using an absolute URL, over a relative one, is to give developers flexibility so they may have an external service where it makes sense to do a remote request.

Scheduled Site Health checks

Since asynchronous calls were less than ideal to query from a scheduled event when run locally, #48105 and #51547 introduce the async_direct_test argument to a test array. This argument should be a callable instance of your test, that can be run directly, without an asynchronous call.

Asynchronous calls were implemented to prevent slow tests from preventing page loads and timeouts. Such concerns do not exist in the context of a scheduled event.

You still register your tests (or remove ones that are not needed in your scenario) using the site_status_tests filterFilter Filters are one of the two types of Hooks They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. in a way similar to this:

class My_Custom_Feature {

	 * Set up class.
	public function __construct() {
		add_filter( 'site_status_tests', array( $this, 'site_tests' ) );
		add_action( 'rest_api_init', array( $this, 'register_rest_route' ) );
	 * Register rest routes.
	public function register_rest_route() {
					'methods'             => 'GET',
					'callback'            => array( $this, 'run_test' ),
					'permission_callback' => function() {
						// Perform any capability checks or similar here.
						return current_user_can( 'view_site_health_checks' );
	 * Filter Site health tests to add our custom test.
	 * @param array $tests An associated array of existing tests.
	 * @return array An array of available tests.
	public function site_tests( $tests ) {
		$tests['async']['my-custom-feature'] = array(
			'label'             => __( 'My feature label', 'my-feature' ),
			'test'              => rest_url( 'my-custom-feature/v1/test/is-working' ),
			'has_rest'          => true,
			'async_direct_test' => array( $this, 'run_test' ),
		return $tests;
	 * Run our test to check if the test is reachable.
	 * @return array An associated array of test result details.
	public function run_test() {
		$result = array(
			'label'       => __( 'My custom function test', 'my-feature' ),
			'status'      => 'good',
			'description' => __( 'The callback to this test worked', 'my-feature' ),
			'test'        => 'my-custom-feature',
		return $result;

// Initiate custom function.
new My_Custom_Feature;

The above example registers a custom rest route with a direct test callback. Additionally, it adds to the array of asynchronous tests available to the Site Health component.

When a check is performed, the result will be a passing test saying the test is reachable. If the check is run during a scheduled event, the test will not use the REST API endpoint. Instead, it will call the test directly.

The REST API handling also added improved checks for HTTPHTTP HTTP is an acronym for Hyper Text Transfer Protocol. HTTP is the underlying protocol used by the World Wide Web and this protocol defines how messages are formatted and transmitted, and what actions Web servers and browsers should take in response to various commands. failure states (previously it looked for an instance of WP_Error, which is not returned in the case of a REST API error), and better listing of asynchronous tests that fail for the site user. It now informs the site user of any failures that have an error state.

Props @planningwrite for copy-edits and proofreading.

#5-6, #dev-notes