Downtime Monitoring

Jetpack’s downtime monitor will continuously watch your site and alert you the moment that downtime is detected.

Jetpack keeps tabs on your site and notifies you the moment downtime is detected.

Once 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 an email notification to the WordPress.com account that Jetpack is connected to.

For general features and FAQs, please see our features page.

Emails

When downtime monitoring is activated, downtime notification emails will be sent to the user who activated it. If you have additional admin users connected to their WordPress.com accounts, they can also enable these email notifications for themselves via Jetpack → Settings → Security.

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.

Push notifications

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 this feature from the web:

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

In order to enable this feature from the apps (Android and iOS, Jetpack and WordPress):

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

Is your site up and running properly, but you’re receiving ‘site down’ notifications?

This can happen for different reasons, and the content of the Notification emails should tell you more.

Status Alerts

At the bottom of the Notification email we send you when monitoring detects an issue with your site there is a section that can provide a little more information:

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.
• “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.

How does this work behind the scenes?

When we check your site, we ping your site’s homepage (via a HTTP HEAD request) every five minutes.

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 datacenter.

If all three checks fail, we mark the site as down and notify you.

Note: Jetpack uses the timezone set in your WordPress settings (Settings > General)

Privacy Information

This feature is deactivated by default. If you ever need to deactivate this feature, you can click on the Settings link in the Downtime Monitoring section from Jetpack — Dashboard — At a Glance in your dashboard. Once you’re viewing the feature’s settings on WordPress.com, toggle the Monitor your site’s downtime setting found within the Downtime Monitoring section at the top of the page.