Notifications are a key piece of any monitoring service. They are used to alert the correct person of problems quickly when they happen, so you can react to service interruptions before very many of your customers or users are impacted.
Some services send you notifications every time a service fails a check, even if you already know about it. In our experience as monitoring service users, too much noise in the notifications leads to missing important information. Our goal in designing the notification system for NodePing was to make sure you are notified of status changes in your sites or services, but at the same time keep the level of notification noise at a minimum.
NodePing's notification system sends alerts when the status of a service changes. So you will get a notice when NodePing's checks recognize that a service has gone down, and you will get another notice when the service comes back up. We do not send notices in between, because you already know. This is designed to make sure that if you get a notification message from NodePing, it is always something you want to pay attention to.
There are other pieces of the puzzle involved with making sure that every notification is meaningful. The most important is tuning your site monitoring check settings. If you put the check threshold setting too low, for example, you will get notices that don't give you any useful information (useful here meaning that if you get a notification, there is something you should do to the service immediately). Generally you should set the threshold to tell you when there is a problem that requires an immediate response, and use the reports to see if your website performance is acceptable. Setting the threshold low to notify you when the site is slow usually leads to not paying enough attention to the notifications.
NodePing site monitoring services include unlimited international SMS and email notifications. Most checks use email notifications. SMS is typically used for notifications on services that are more time critical, or at times of day when email is likely to not be seen for several hours (especially at night).
Get push notifications from Pushover on your iOS and Android devices. 'Emergency' notifications are sent when a check fails and will automatically re-alert every 30 seconds until the notification is acknowledged, up to 5 minutes. Try sleeping through that! Pushover notifications are faster and more reliable than SMS and also allow NodePing to keep prices low. Please consider using Pushover notifications instead of SMS. You can download Pushover to your device from the appropriate app store and then enter your user key in the notification type text box and choose 'Pushover' from the drop down menu. Select the Pushover key you entered when creating or editing a check and you will receive notifications on each check event.
The Provider plan includes unlimited voice notifications worldwide. We'll call your phone and a soothing robotic voice will calmly tell you that your server is down... or that it has come back up. You'll need a specific entry in your contact record for each voice number. Enter the voice number and select 'Voice' from the dropdown.
Add your twitter handle (including the leading '@' sign) and follow @NodePing and we'll be able to send you private direct message notifications.
Webhook notifications are included in our Business and Provider plans as well. Add an entry in your contact record by specifying the full URL you wish our service to hit when a check fails and comes back online. Our service will issue an HTTP GET request to that URL and pass the following information in the query string.
Integrate your PagerDuty notifications with NodePing server monitoring. Our system will send a 'trigger' event on each failure and a 'resolve' on each recovery. You'll need to use a 'Generic API Service' in your PagerDuty account and add an entry in your contact record by specifying your PagerDuty 'Service API Key' and selecting 'PagerDuty' in the notification type drop down. You can specify as many different PagerDuty contacts as you like. This allows you to use multiple 'Services' and have full control of your PagerDuty escalations and notifications. This notification type is currently only available on 'Business' and 'Provider' plans.
Receive NodePing notifications in your perferred Slack channel. Set up an incoming webhook in your Slack account and put the webhook URL into your 'Slack' notification contact to receive 'down' and 'up' messages on the configured channel. This notification type is currently only available on 'Business' and 'Provider' plans.
The Sensitivity setting on NodePing checks puts two considerations into one simple setting. The setting configures how many times NodePing should recheck a service before sending notifications that it is down. The first part of this is "flapping." Flapping occurs when a service is rapidly changing between up and down states. This happens particularly on shared web hosts, when some other site is consuming resources on the same server as the monitored site, or other similar situations in which the available resources to provide the service are marginal. If the monitoring checks notify on a single check result in those situations, notifications will be sent out when the site appears to be "up." These problems are often very transient, and lead to notifications that aren't really very actionable especially if you are already aware that the server is prone to this type of issue. Setting the Sensitivity lower causes NodePing to recheck the service more times before reporting it as down. The number of rechecks for each level of Sensitivity are:
The rechecks happen several seconds apart, so that on a setting of "Very Low"" a site can be down for approximately 90 seconds before it is marked as down and we send a notification. Sometimes that's exactly what you want, but most often a Sensitivity setting of "High" is best. "High" ensures that the check didn't fail for very transient reasons (such as a router hiccup somewhere), but that the notification is still sent promptly, typically within 30 seconds of the original scheduled check time.
The second consideration in rechecks is check location. When NodePing detects that the status of a service has changed, it automatically reschedules rechecks to occur in a different location. It is uncommon, but sometimes a check can fail because of something unrelated to the service being monitored. For example, a router in between the NodePing pinghost server and the website could be acting up. Getting a notification because some router out on the Internet somewhere is having problems is not useful information. So, NodePing rechecks the service from a server at a different geographic location to make sure the cause of the status change is really the service being monitored. For example, if a check is set to "High" Sensitivity and a check from New Jersey shows that it is down, the system will automatically run the rechecks in other places. The first recheck might be in Texas, and the third in California. The recheck's location is not predictable, the system just sets it to run "elsewhere." We do that to enable multi-site rechecks without complicating the service's check configuration. As a result, as long as your Sensitivity is not set to "Very High" (which skips rechecks and just sends the notification imeediately), you automatically get geographically dispersed rechecks without any further configuration required.
Many services require notifications 24 hours a day, seven days a week. For those services, the default "Always" setting for notifications works great, and configuring the monitoring is simple. For other services, you want notification to a particular person during a certain time of day, and notification to someone else during a different time of day. Often these correspond to different people's work schedules or an on-call rotation. You might want email during work hours and SMS after hours. Some services only need notifications to be sent if they are down during office hours, and others only if they are down when someone is not already paying attention. All of these different notification needs led to NodePing's notification scheduling functionality. We think the service provides a good balance between flexibility, to handle all these different needs, and simplicity in the amount of configuration you need to do to get it set up.
NodePing provides five notification scheduling "windows" by default: Weekends, Weekdays, Days, Nights, Always, and Never. You can customize all of these for your specific account except for Always and Never. You can also add additional notification windows. For example, you might want a schedule for the swing shift or evenings, or something unique to your company. Some schedules include notifictions all day (midnight to midnight) some days, and none at all other days. The opposite of that is to have some days with no notifications at all, which uses the "Disable" toggle for that day. Weekends and Weekdays are examples that use both of those settings. The Invert toggle is used to cause notifications to be sent at all times except for a certain window. This is used for the Nights schedule, which is intended to schedule notifications at all times other than business hours. All of these are completely optional, and can be adjusted to meet your specific needs.
The Notification Windows page also allows you to set the time zone for your account. This time zone setting is just used for notifications. Take not that if you observe Daylight Savings Time or DST that NodePing does not automatically adjust your time zone setting as it is an offset of GMT. Please be sure to adjust your timezone if you observe DST. For time actually displayed on reports and graphs your computer's time zone is used automatically by your browser and will reflect DST if your computer does.