Alerts in RapidSpike are configured in two parts. First, you must create one or more Alert Delivery Groups. 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 Alert Delivery Groups

Go to “Global Settings” in the left blue menu.

From the menu that appears below, select “Alert Delivery Groups”.

This page will show your existing Alert Delivery Groups, if any, each requiring a label and a colour.

To create a new Alert Delivery Group, click the green “Add Delivery Group” in the upper right corner of the page.

Each group requires a label and a colour to easily discern different alerts. In the form that appears you can edit the sensitivity of the Uptime Monitor Alert rules – this is the amount of time an uptime monitor is classed as ‘Failing’ before an alert is sent out. You can also customise which users to alert, and the method by which they are alerted.

In this form you can also configure alerts to be sent to your integrated tools, such as: Slack Message, Webhooks, PagerDuty and Pushover.

Note: 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

Creating 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. For example, if 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 more targeted and sophisticated monitoring of your platform.

In the left blue menu, below “Global Settings”, you can create rules for a range of monitors. Rules determine when and why your Alert Delivery Groups receive an alert.

On each of these pages your existing alerts are displayed. You can create a new rule, using the “Add Rule” button.

Each page has an individual form to customise an an Alert Rule for each type of monitor. For example, below is the Performance Alert Rule form.

In each form you can adjust why and when the alert is sent, and which Delivery Group it is sent to. 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 to ‘Z’ group.”

In the Security Rules tab in the left blue menu, you can create alerts for Security Scans, Magecart Detection and Malicious Users.

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.