Stakeholder engagement: keep stakeholders in the loop during critical incidents
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
- Internal stakeholders within your organization, e.g. executives, the marketing team, customer support team, or other departments
- External stakeholders outside your organization, e.g. if you’re an IT service provider and want to keep your customers in the loop about an ongoing incident.
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.
Improved uptime reports
We have greatly improved the usability of uptime reports:
- You can now brush within the chart area to zoom
- The upper chart lets you navigate through the selected time period
API end point for uptime monitors
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.
Support for milliseconds in check timeout
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.
Flexible periods in repeating on-call schedules
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.
New and updated integrations
- Icinga: there is a dedicated plugin for Icing-a now on our GitHub repo. You can now override the incident priority from within Icinga and we include the comments that you enter in Icinga when ack’ing a problem in the event log of the incident.
- JIRA: When you setup a connection from your alert source in iLert to your JIRA instance, projects and issue types are now dynamically fetched from your JIRA instance, so you can select the issue types when iLert syncs an incident to JIRA. You can even include custom fields. See our JIRA integration guide for further information.
- Webhook integration: you can now fully customize the payload for outbound webhooks. See our Webhook integration guide for more information.
- AWS Personal Health Dashboard
- Serverless outbound integrations:
XML API Deprecation
Support for XML payloads in our REST API is deprecated and will be fully removed on August 1st, 2020.