uptime monitor service notes

fyi: server uptime monitor and alert service - exactstate.com
These notes will help you get acquainted with the monitoring and alert services and help you get the best results as a user.

Additional information is available in the user manual.


The monitoring service is capable of testing for responses from http, https, ftp, smtp, pop3, imap, telnet, ssh, ping and custom tcp ports. The testing interval can be set at 1, 2, 5, 10 and 20 minute intervals.

All test measurements are conducted in parallel from multiple locations. On failure, a recheck is scheduled immediately for the following minute. The recheck is intended to catch transient errors that disappear shortly after the initial error.


Email blacklist monitoring is available for individual servers or ip address blocks. Blacklists are checked every 4 hours for individual smtp servers. Right hand side domain name blacklists are checked every 4 hours. Bulk ip address blocks are checked against ip address blacklists every 24 hours.


There is no software to install and it makes no difference if you are running Apache, IIS, Sun or Zeus. All of the software runs on our servers. All a subscriber needs is a web browser to access the control panel and a way of receiving email or sms alerts.


Internal monitors can give you very fine grained detail of the inner workings of your servers and internal network. The problem is that it can mask network problems outside of the local network. Internal monitors are also usually unable to send alerts if the the monitoring server or internal network fails.

The goal of public facing web sites is to make sure that the site is available at all times to external users. External monitoring is best suited to ensuring that this goal is met because it uses external access routes just like external users and are independent of the facilities being measured.

Furthermore, as an independent data source, it is useful in discussing service difficulties with network and hosting providers.


Payments are accepted from major credit cards, bank transfers and paypal balances through the paypal payment clearing facilities. There is no requirement that the subscriber have or maintain a paypal account when using a credit card. No credit card numbers or pin numbers are made available to, or stored by exactstate as the information is directly submitted to paypal and processed on their systems.


The uptime monitoring method uses the same process used by your users. The following example applies to tests of http servers. The elapsed times and results for each step are recorded for detailed reporting.


You can have alerts sent to multiple email addresses or sms devices. This includes email addresses provided by your cell phone or pager service provider. To find out if free email access to your sms phone or pager is available, check with your service provider. You can also check this list of carrier free email to sms address formats


Every account can initiate alerts to multiple accounts and can receive alerts from multiple accounts. Each receiving account controls the acceptance of alerts as well as the notification path and schedule. This flexible routing scheme permits participation by every user in multiple service groups.

It is strongly recommended that each person have their own account and control their own notification channels. Some accounts will never be charged because they exist solely to receive alerts. All alerts are charged to the originating account.

Originating accounts can withdraw alerts to receiving accounts. Receiving accounts can refuse any alert in addition to setting the notification path and timings. All participating accounts have access to alert details and can insert log notes about a particular alert. However, only the originating account can modify the test parameters.


An alert is scheduled only if there is not at least one satisfactory response from the parallel testing procedure. Failures are also suppressed if the error rate is too high during a test cycle. This is intended to prevent false alerts if our own connections are having problems.


The goal of the monitoring service is to alert subscribers when the monitored server is not generally available to all users. While it is possible that a specific user can reach the server successfully using a particular network route, the alert is reporting that the server is not completely available. This is a condition that administrators must allow for when evaluating alerts.


A recovery notification is sent at the time of the first successful test after a failure if a failure alert was previously scheduled and sent. This feature is addressed at those situations where the alert recipient has not yet been able to respond to the alert. For example, the responsible party might have been on the highway at the time of the initial alert.


Alerts are capped at four alerts per destination per incident. An incident is defined as a transition from a pass state to a fail state for as long as it remains in a fail state. This feature helps to avoid depleting accounts when the responsible parties are already quite aware of a long running failure that is beyond their control.


Alerts are cancelled if a retest of the failure returns a successful response before the initial alert delay period setting has expired.


Subscribers have full control over the timing of alert transmissions for each individual test target.

Configurable options include:

This ensures that only valid alerts are sent, that the alert is sent via the most suitable path, and that escalation channels are automatically invoked.


You must use at least one alert that bypasses any mail server that is dependent on the monitored server and network. If you do not, you will not receive alerts in a timely fashion. This is because if the server or network that is being monitored fails, it is of course, also unable to receive email alerts for you.

It is perfectly acceptable to retain your usual email address as the default destination for reports and backup warnings.


You can monitor backend services by performing the backend tasks in your page source code. On success, return the page with a 200 status code, otherwise return the page with a 500 error code.


To monitor the uptime of load balanced server clusters you will need to take some additional steps. The monitor for the public url of the site should be configured as usual. This will cause alerts to be forwarded if your site becomes completely unavailable. Then, add a monitor for the url of each of the individual servers that make up the load balanced cluster. For example, if your site www.example.com is served by four servers named 1.example.com, 2.example.com, 3.example.com, and 4.example.com, then you will need a monitor for each of the servers 1 through 4 and one for www.example.com


Status codes in the 100,200,and 300 series are interpreted as successful responses. Status codes in the 400 and 500 series are interpreted as failures. The absence or status codes in any other range are interpreted as failures. Further information can be found in RFC 2616


e-commerce services uptime statistics are available publicly on the e-commerce uptime statistics page.

The e-commerce infrastructure services categories include

Subscribers can add alerts for individual services to their personal alerts.


Our services are intended for the usage of people with a legitimate connection to a site. For example webmasters, site managers, hosting personnel, site owners, etc.

It is not recommended that subscribers create monitoring profiles for external sites not under their control.

If a complaint or request is received from a verified site owner as determined by published whois information, all historical data will be moved to their account and the associated alerts disabled.

The recommended method of obtaining alerts for sites not under your control is to ask that it be added to the list of public monitors. That way, the site data is available to all interested parties without unduly burdening the server with multiple requests.


All subscriptions, including add-in subscribers, are verified by requiring acceptance and verification using a uniquely coded response from verification emails sent by the subscription management system.


Per incident diagnostics assistance is available from experienced server and network administration experts. It is also possible to arrange special high intensity monitoring in order to trace intermittent problems. Please see exactstate.com


exactstate.com has listed its servers for independent third party uptime monitoring at netcraft.com. To see our stats, click here.


Calculating five nines uptime is not always an easy task for everyone since it involves mixing percentages, decimals and time conversions in the same calculation. A precalculated chart of the actual times that varying levels of percentage uptime imply is located here.


Some of the names we have seen used for server uptime monitor and alert services are:

source: exactstate.com