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.
Use cases for heartbeat monitoring
With heartbeat monitoring, you can get alerted
- if your monitoring tool stops working
- if your internet connection (and your connection to iLert) is interrupted
- if any of your cron jobs did not execute successfully
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.
Heartbeat example: monitor cron job
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
0 0 * * * daily_backup.sh && curl https://api.ilert.com/api/v1/heartbeats/il1hbt092081aee295d6ff4954a24f83c476fa40bd5cb28315a4
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:
- Create a JIRA issue in project X
- Restart server
- Revert last commit
- Post a message to teams chat
- Send an email to a distribution list
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.
Incident re-routing and suggested responders
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.
Call routing: time management using support hours
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.