Vigil makes it easy to setup monitoring for your website. Give us a URL, and we'll start checking it using our default monitoring options. There might be times when the default options are not appropriate, or you want to test more complex scenarios. Vigil has a number of options you can configure that will change how we check your site.
The sensitivity setting controls how many failed connection attempts it takes before Vigil considers a site down, as well as how many successful checks it requires before it then considers it back up. Most sites and hosting providers experience some intermittent networking issues which can cause false alerts, even though a site may still be up. We recommend users use the normal setting.
Vigilant Vigil will send a down alert after a single failed connection attempt, and will only send out an up notification after five successful checks.
Normal Vigil will send a down alert after three failed checks in a row, and will send out an up notification after one successful check.
Relaxed Vigil will look for 5 failures in a row before sending out a down alert, and will report a site as up after a single successful check.
Off We will not send a push notification when a site goes down or up.
REPORT SSL ERRORS
As part of our site check, we validate the SSL certificate for secure sites. If your certificate is expired, or self-signed, we report it as an error. Setting this option ON will cause us to report an alert if the certificate fails a check. Your site may still be downloading okay, but most browsers would show an error to the user that the site is considered untrusted. In some cases, your certificate may be okay, but the server itself may be misconfigured.
Internet addresses have traditionally used IPv4 addresses which are represented as a dotted notation with four numbers (for example 192.168.0.1). These addresses have been exhausted, and most service providers are switching to IPv6 addresses. However, using IPv6 requires several services working in concert, including the DNS lookup, routing and web server itself. The Vigil monitors will use either method, falling back to the older IPv4 address if needed. If you would like to specifically test for IPv6 support of your website, you can toggle ON the Use IPv6 option. This will report if we are unable to reach your site solely through IPv6 addresses.
A web server can indicate that a page has been moved either temporarily or permanently. These redirects give the new location, and by default Vigil will follow the redirect and attempt to load the web page at the new address. A redirect is not considered an error unless the new address doesn't work. If you want redirects to raise an alert, you can turn OFF the Follow Redirects option.
All web servers will provide a status code along with any data. These status codes can communicate many different issues the server might run into while processing a request. By default, we consider anything in the 2xx range to be a satisfactory response. If you want to further restrict which codes are considered okay, you can de-select codes from the Status Code screen. While not typical, in certain situations you may want to even pick status codes that are reporting an error. For example, you could set up a monitor to test an API endpoint that reports and error condition, and want that status code to be considered OK.
By default Vigil makes a HEAD request. This asks the server for only the initial data, saving you bandwidth, but still requiring the server process the entire page. Even though a server responds with content, it may not be the content you expect. Depending on how your server works, the content that fills your pages may rely on additional subsystems which may be having issues. By using the Content Check option, we will request the entire HTML content of the page, and search for the string you provide us. This helps to ensure your server is providing your visitors the content you expect.
Most web page requests use the GET method, and this is the method we use when requesting a page from your site. The HTTP protocol provides a number of additional methods typically used when submitting or editing data on a server. These include PUT, POST and DELETE. If you are using the Vigil web client you can change which method we use. Some of these methods only make sense if you also provide custom headers or data in the request. You can use these options to make more advanced requests to REST endpoints that may not have traditional user-facing website functionality.
Every HTTP request includes custom headers. Some servers use this header information to customize the information they provide. You can add custom headers to your request that will be sent along with each monitor check. Custom headers are provided as a comma-separated list like:
If you are using a custom method, you may want to pass along data in the body of the request. This data will depend upon the request you are making, and might include sample form data or other REST content. this option is available on the web client.
As you can see, there are a number of ways to customize how we monitor your website or web service. Whether it is a simple home page, or a database-backed REST API endpoint, Vigil can help make sure it is available for you and your customers. If there is a configuration option you don't see, or need help with what settings might be appropriate for your use-case, please get in touch with us. We are always happy to help, or receive feedback.