Nowadays, a working digital infrastructure is the lifeblood of almost any organization. The impact of a major IT incident can go far beyond the IT department, affecting a company’s revenue or incur costs in other areas of the business caused by service disruption. Therefore, in addition to the technical response to a major incident from the IT department, business stakeholders need to be involved as well, so they can prepare the business response.
With iLert’s Stakeholder Engagement feature, on-call teams can keep stakeholders informed during an ongoing incident with minimal effort while focusing their time on incident resolution.
Use cases for stakeholders may include
Stakeholders will only be able to see the incidents to which they’ve subscribed to and won’t be able to see any other data, such as other incidents, alert sources, escalation policies, etc. Checkout our documentation for more information.
Stakeholder Engagement is part of our Premium plan.
We have greatly improved the usability of uptime reports:
Uptime monitors can now be fully managed through our REST API, giving you the option to automatically create, pause, and delete uptime checks as well as embed uptime reports in your applications. This blog post from our engineering blog walks you through a code example using NodeJS.
Until now, you were able to set a timeout as low as 1 second for your uptime checks. While this is more than enough for most scenarios, sometimes you want to make sure that the end points you’re monitoring respond in the sub-second range. You can now set the timeout value for your monitors in milliseconds.
This is a small, but mighty improvement to repeating on-call schedules. You can now set an arbitrary period length and chose between days and weeks as the period unit. This lets you create arbitrary rotations.
Support for XML payloads in our REST API is deprecated and will be fully removed on August 1st, 2020.
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.