Alerts in RapidSpike are configured in two parts. First, you must create one or more Delivery Methods. These are a way of saying WHO gets notified, and HOW. You then make an Alert Rule, to which you attach one or more Delivery Methods.

Creating a Delivery Method

In the Alerts section of the app, click the Delivery Methods tab, and then on the Add Delivery Method button.

Delivery methods require a name and a colour – this is to help you find them more quickly. It’s up to your what delivery methods to create – this depends on your team and how you want to manage the alerts that go out. Some suggestions:

For larger businesses, it might be necessary to create different delivery methods for each department that needs to be notified. e.g. you may have a method for your Client/Customer Support team, a separate method for your Development team, and a third for Management.

Another way to set up your delivery methods is to create different methods with scaling urgency. For example, the first method will simply email or send a Slack message to the developer associated with the project. The second method will text/call their manager. The third contacts the business owner. You would then apply these methods at different times as a way of escalating a problem if it lasts for too long. E.g.:

• Shopping Cart page is down for 1 min: Email developer
• Shopping Cart page is down for 10 min: Text Development Team manager
• Shopping Cart page is down for 30 min: Call Business Owner

An example of a variety of delivery methods

In RapidSpike you can add as many team members to a Delivery Method as you like, and contact them through a variety of different means, including:

• Email
• Voice Call
• Text (SMS) Message
• Slack Message
• Webhooks
• PagerDuty
• Pushover

Making Alert Rules

Alert Rules set the conditions that trigger a notification. In the case of uptime monitors, this is usually because the monitor is deemed to be failing. I.e. you have configured an “Expected result” (status code, response time, port state) and the expected result does not match the actual result.

For our more advanced monitors, however, alert rules can be much more detailed. For example, with a User Journey you can configure an Alert Rule to fire when a specific element type has exceeded a particular load time or file size. These alerts let you set up granular and sophisticated monitoring of your platform.

Please note, however – that some rules may take some adjustment before they are perfect!

Alert Rules are different for each monitor type, but generally they follow a simple formula:

If ‘X’ condition occurs, and it has happened ‘Y’ times, then trigger the alert

Some examples:

A simple User Journey rule example

A slightly more complex IPM rule example

The final step is to attach one (or more) Delivery Methods, depending on who you would like to be contacted.

Note:

Availability (Uptime) rules differ slightly from the more advanced monitor rules, in that they do not require any conditions setting. This is because the conditions exist on the monitors themselves – in the form of an “Expected result”. For example, HTTP monitors have an “Expected Status Code”. If this expected code does not match, then the monitor is deemed to be failing.

Instead for Availability Rues you just need to apply a Delivery Method to determine who will be contacted.