Monitor your site’s uptime and downtime

Jetpack’s downtime monitor continuously watches your website and alerts you the moment that downtime is detected.

Once Jetpack’s Downtime Monitor is activated, one of our servers will start checking your site every five minutes.  If it looks like something’s gone awry, we’ll fire off a notification to the WordPress.com account that Jetpack is connected to. For more information and FAQs, please see our features page.

Requirements

Jetpack’s Downtime Monitor needs a working Jetpack connection. To activate the feature, you need to install and activate the Jetpack plugin.

Jetpack’s Downtime Monitor is a free feature, it does not require a Jetpack plan.

Activate/Deactivate Downtime Monitoring

You or additional admin users connected to Jetpack can activate or deactivate the downtime monitoring feature from your WP Admin dashboard:

1. In your WP Admin, Navigate to Jetpack → Settings → Security
2. Toggle Downtime monitoring to:
   • On if you wish to receive Jetpack Monitor notifications when your site goes offline.
   • Off if you wish to stop receiving Jetpack Monitor notifications about your site going offline.
3. Choose if you want alerts via email and/or WordPress.com notifications.

Emails

When downtime monitoring is activated, downtime notification emails will be sent to the user(s) who have enabled them in their WordPress.com security settings.

The time and date used in the notification comes from the timezone set in your WordPress settings (Settings > General).

If you’d like to add something to your email filters to make sure these notification emails never get sent to spam, they’ll all be coming from support+monitor AT jetpack DOT com.

If you are still getting downtime notifications for a site you no longer manage, please contact support.

Who receives downtime emails?

Downtime notification emails are sent only to the WordPress.com account that originally connected Jetpack to your site. This is typically the site’s primary user or Jetpack connection owner. It isn’t currently possible to add or CC additional recipients for these emails.

Enable notifications about downtime

You can now receive notifications about your site being down on the web through WordPress.com and/or push notifications on mobile (Android and iOS) for both Jetpack and WordPress apps. 

In order to enable downtime notifications via WordPress.com:

1. Head to https://wordpress.com/settings/security/.
2. Select your site.
3. Enable “Send notifications via WordPress.com notification”.

In order to enable downtime notifications from the Jetpack app or WordPress app go to:

1. My Site.
2. Jetpack Settings.
3. Enable “Send push notifications”.

You received a downtime alert, but your site is not offline

Sometimes, Jetpack Downtime Monitor may alert you even if your site appears to be running normally. Here are the most common reasons for these false positives:

• Your site is responding intermittently or too slowly.
  If your site takes longer than 20 seconds to load, we consider it inaccessible and trigger an alert. This often happens on shared hosting, where server resources are limited and shared with other sites. Heavy home pages with many loading resources can also slow things down.
  If you received only one alert and your site quickly returns to normal, it’s likely the issue was temporary and has already resolved itself.
• Too many redirects.
  If our monitoring agent encounters excessive redirection, it may trigger a downtime alert. Double-check that your site’s URL is set up correctly and review any redirection plugins that might be misconfigured.
• Jetpack is being blocked.
  Some hosting providers may block Jetpack’s monitoring agent. Ensure that your host allows requests with the following user agent:
  jetmon/1.0 (Jetpack Site Uptime Monitor by WordPress.com)

If you’re unsure or still encountering issues, please contact support for help.

Status Alerts

At the bottom of the Notification email we send, there is a reference number that provides more information. It will be something like [23454191/server].

The number is our internal I.D. for your site. The second part is the status which is being returned. These are based on the HTTP response code to the HTTP HEAD request to your site’s home page:

• “server” — a 5xx response, meaning the server had some type of fatal error, in particular if your theme or one of your plugins creates a Fatal Error.
• “blocked” — a 403 response, meaning the server replied that we were forbidden from viewing the home page.
• “client” — a 4xx response (other than 403), suggesting a similar server-side setting disabling access.
• “intermittent” — the request timed out without a response after 10 seconds. This case is one that can be confusing, since the site may actually be loading, just really slow. This one is also most likely to self-resolve–if the site is on a shared host and another site on the server is using too many resources, it could cause the other sites on the server to respond slowly. Note that our primary monitor server and the multiple verifying servers would all be seeing this for us to mark the site down.
• “redirection” — a 3xx response. Monitor will follow a few redirects, but if we’re asked to follow a fourth redirect, we assume there is a problem. Realistically, the suggests a redirect loop, but could be a relatively poor setup (e.g. example.com -> http://www.example.com -> http://www.example.com/en/ -> http://www.example.com/en/blog/ would be seen as down).
• “success” — a normal response. Everything worked. This should only be seen on the follow-up “Your site is back up!” e-mail.
• “unknown” — this shouldn’t ever happen. It suggests our monitoring service didn’t send an expected response to WordPress.com.

Testing Monitor

You can run the following command in Terminal to check if the Jetpack Monitor agent is being blocked. If your site is up, it should return 200:

curl -IA "jetmon/1.0 (Jetpack Site Uptime Monitor by WordPress.com)" https://jetpack.com 

You will need to replace jetpack.com with your site’s domain.

How does this work behind the scenes?

When Jetpack checks your site, it pings your site’s homepage every five minutes, via a HTTP HEAD request.

We tentatively mark your site as down if the HTTP response code is 400 or greater, which indicates either a permissions error or a fatal code error is prohibiting your site from appearing to visitors, or we see more than three 300-series redirects, suggesting a redirect loop, or if your site fails to respond within 20 seconds.

Once it is tentatively marked down, we then spin up three separate servers in geographically different locations from a third-party vendor to ensure the problem is not isolated to our network or the location of our primary data center. If all three checks fail, we mark the site as down and notify you.

You can test to see if Jetpack Monitor is working on your site by running the cURL (client URL) command below, replacing “yourjetpack.blog” with your own site URL:

curl -IA "jetmon/1.0 (Jetpack Site Uptime Monitor by WordPress.com)" https://yourjetpack.blog

A response of 200 OK indicates that it is working.

Known Issues

Missed downtime notification and Cloudflare

If you’re using Cloudflare and the site is down, Downtime Monitor may not be able to notice it. This is due to how Cloudflare works, when the origin server (web host) is down, a cached copy of the site will be served by Cloudflare; because of that, Downtime Monitor will see the cached copy and won’t detect the downtime at the origin server.

Offline/non-operational sites still receiving Monitor alerts

You may still receive downtime notifications from Jetpack Monitor for your closed, no longer existing site. This happens because Jetpack Monitor continues to check the site’s status unless the Jetpack connection is stopped.

If you are receiving unwanted notifications and no longer have access to the WP Admin area for the site, you can disconnect Jetpack via the WordPress.com Dashboard.

Privacy Information

Downtime Monitoring is deactivated by default. You can activate it from your WordPress.com dashboard under Settings → Security.

Data Used
Site Owners / Users Site owner’s local user ID, WordPress.com user ID, email address, WordPress.com-connected blog ID, and the date of the last downtime status change. Additionally, for activity tracking (detailed below): IP address, WordPress.com user ID, WordPress.com username, WordPress.com-connected site ID and URL, Jetpack version, user agent, visiting URL, referring URL, timestamp of event, browser language, country code.	Site Visitors None.
Activity Tracked
Site Owners / Users We track when, and by which user, the feature is activated and deactivated. We also track when, and which, configuration settings are modified.	Site Visitors None.
Data Synced (Read More)
Site Owners / Users We sync options that identify whether or not the feature is activated and how its available settings are configured.	Site Visitors None.