Stratus HTTP Monitoring

Webscale STRATUS has active HTTP monitoring for sites. Webscale also monitors the root domain, and accepts redirects to avoid duplicate alerts.

NOTE: For infrastructure level alerts, please subscribe to the Webscale STRATUS Status page.

Criteria

Webscale STRATUS has active HTTP monitoring for sites if they meet the following criteria:

  • The domain exists in the URLs panel of the Webscale STRATUS environment panel.
  • The domain is on a production Webscale STRATUS environment, i.e. not a development environment. Development domains are not monitored.
  • A valid SSL is applied that covers your domain.
  • MageMojo have been granted Google Analytics access to validate session usage. Nonvalidated domains are not monitored.
  • The domain is not behind a proxy service like Cloudflare or Sucuri.

Webscale also monitors the root domain, and accept redirects to avoid duplicate alerts. www.example.com is not directly monitored, but example.com would be and, if redirected to www, the last redirect status code is recorded.

If there are additional domains/pages that need to be monitored, there are several third-party services available.

Alert conditions

Rather than monitoring for every possible failure, our monitoring is focused on identifying system-side issues within Webscale STRATUS. We only monitor the following status codes:

  • 502
  • 500
  • 504

404, 401,403, 503, etc. alerts are ignored. Customers frequently restrict their sites and make changes that cause error responses. Though they are not really causes for alarm. 50x errors are almost always an issue with the code-base, configuration, or the Webscale STRATUS system.

Errors are also triple checked before an alert is fired. We exclude certain conditions if detected, such as:

  • The site is suspended (sends a 504)
  • Services were recently restarted (customer action causing a 504)
  • A domain was removed from the URLs list by a customer

What happens when an alert fires ?

When an alert meets our conditions, the following sequence is triggered:

  1. A ticket opens to the environment owner’s account and any authorized users are copied on the ticket.
  2. Our internal system sends a Slack message to our Support team.
  3. A support tech will verify the issue and work to resolve it, with an Root Cause Analysis follow up. The RCA will include recommend actions to avoid future outages.

Last modified January 1, 0001