Alert resolution report

[Henrik Jutterst]

Manager from 24/7 team would like to have a report on the level of Alerts being resolved by users or automatically. But since Alert record is overwritten every time - either by an event  or closed by user in incident - what is the best way/preferred way to have such a report?

Can Performance Analytics help out in this case?

Another alternative is to add custom fields on Alert record (counters; resolved automatically, resolved manually, resolved total) and just use them as a counter.

We can also create a new table to write this to, but then there is also this thing with number of custom tables, and not really sure about that solution.

So, anyone here with info on how to help out here?

Kind regards

/Henrik

[Ratnakar7]

Hi @Henrik Jutterst ,

To track and report on the level of Alerts being resolved by users or automatically, here are a few options you can consider:

1. Performance Analytics: Performance Analytics in ServiceNow can be utilized to create reports and dashboards based on specific metrics and indicators. You can set up indicators to track the count of resolved Alerts and differentiate between those resolved automatically and manually. Performance Analytics provides various visualization options and allows you to schedule and share reports with stakeholders.

2. Custom Fields on Alert record: As you mentioned, adding custom fields on the Alert record to track the count of resolved Alerts (automatically and manually) can be a straightforward solution. You can create numeric fields for each counter and increment them based on the resolution method. For example, when an Alert is resolved automatically, you can use business rules or workflow to increment the "resolved automatically" counter. Similarly, when an Alert is resolved manually, you can increment the "resolved manually" counter. This approach gives you flexibility in reporting and can be easily customized based on your reporting requirements.

3. New Table: Creating a separate table to store Alert resolution information is another option. You can create a new table with fields to capture the resolution details, such as Alert ID, resolution method, resolution timestamp, etc. Whenever an Alert is resolved, you can insert a new record into this table to track the resolution. This approach allows you to maintain a historical record of Alert resolutions and provides flexibility in reporting and analysis. However, keep in mind that creating custom tables should be done judiciously as it can impact system performance and manageability.

The choice between these options depends on factors such as your reporting requirements, data volume, performance considerations, and governance policies.

If my response was helpful in resolving the issue, please consider accepting it as a solution by clicking on the ✅Accept solution button and giving it a thumbs up 👍. This will benefit others who may have a similar question in the future.

Thank you!

Ratnakar

[Henrik Jutterst]

Hi @Ratnakar7 and thanks for the reply!

Basically, this confirms my idea of how to solve it. Thanks for writing. I'll keep the post open if I get any more results on where/how this can be done.

Kind regards

/Henrik

[BexT]

Hi Henrik, how did you get on with this report? iv been given a similar requirement - thank you 

[MortenPettersen]

Hi BexT

It's funny how a post from 2023 comes back to life and it's still as relevant today 🙂 Here's my suggestion on how to avoid any custom solution:

I would consider looking at this from a perspective of separating the two disciplines:

- Event Management

- Incident Management

For Event Management, given how the volume is normally at a level where you will realistically never get to assign all the Alerts, or never "resolve" all of them, I suggest focusing on the factors of assignment and acknowledgement. Alerts will auto-close and it will be a difficult and time-consuming activity to keep track of which Alerts got fixed because of the human effort or it just "fixed itself". But you want to know how many Alerts get assigned and how many get's acknowledged because this tells you something about the relevance of the type of monitoring you are doing.

And then you can consider if you want to stop the auto-creation of Incidents (If you are doing this on a global level) and be selective on what type of Alerts will auto-generate Incidents. Consider to switch of auto Incident resolution when Alert closes, and then you just follow the normal Incident process. Which will normally mean that a human agent has to be assigned, and make sure the problem is fixed before resolving it. If this leads to too many Incidents then finetune your auto-Incident creation regime until it's at a level that makes sense. This incentivizes the management of the monitoring so that it is relevant Events coming in.

This might be too much information in one go but the SRE functionality in ServiceNow is really interesting in terms of the ITOM and ITSM intersections. Just a tip. Hope this was useful in some way 🙂