You might have noticed that we’ve added a new type of alert source a few months ago - Heartbeat alert sources:
A Heartbeat alert source expects a signal (the “heartbeat” ping) at regular intervals and alerts you, if it doesn’t receive a ping within the specified interval.
With heartbeat monitoring, you can get alerted
You can even use Heartbeats to monitor IoT devices.
All you need to do is to issue HTTP GET or HEAD requests to your heartbeat URL at at the specified interval to keep your heartbeat alert source healthy.
Let’s say we have a cron job called daily_backup.sh that runs daily and want to ping our heartbeat alert source after every successful run. The most simple method is to append the heartbeat ping command to your cron job using curl:
That’s it! Now, iLert will create an incident and alert you if your cron job fails to execute or did not run at all.
With incident actions, a responder can execute custom defined actions on an incident, either manually, or automatically upon incident creation.
Common uses cases for incident actions are:
Defined actions will be available in the incident’s action menu.
Incidents actions are also available in the mobile app:
To configure an incident action, go to the alert source’s connections page and click on Add new connection.
Then chose your connector type, e.g. JIRA:
Pick the JIRA connector that you would like to reuse or select Create new connection… to create a new JIRA connector.
Fill out the remaining fields and save your connection. Now those actions will be available on all incidents from this alert source.
Assigning an incident is now more flexible. In addition to assigning an incident to another user, you can now assign an incident to an escalation policy or an on-call schedule. If you assign an incident to an escalation policy, the ongoing escalation process will be aborted and the escalation will continue using the escalation rules from new escalation policy.
A third option when assigning incidents is our Suggested Responder feature, where iLert suggests a responder to assign the incident based on historical data.
You can now define support hours on call routing numbers. That way, you are able to route calls to agents during defined support hours and let callers leave a voicemail if they call outside support hours.
As always, incoming calls will open an incident in iLert and you can chose to alert on-call teams on missed calls when support hours begin.
Keep it quiet during maintenance. With maintenance windows, you can temporarily disable one or multiple alert sources for a set period of time. An alert source with an ongoing maintenance will not create any incidents.
With Priority-Based Alerting, you can set different notification rules for high and low priority incidents. That way, you can use more obtrusive alerting methods for incidents that require immediate attention and less obtrusive methods for the ones that don’t. Low priority incident also do not escalate automatically. The incident priority is set on the alert source level. Moreover, the incident priority can be dynamically set based on Support Hours. This gives you the flexibility to be notified differently based on the time of day. You could, for example, configure your alert source to receive voice alerts during the night and push notifications only during work hours.