Besides deciding what you want to monitor, you also must think about who should receive notifications about any issues or events. When using a monitoring product, email is often the first choice for sending notifications. However, monitoring products exist that enable you to send notifications via products such as Slack, ServiceNow, SMS, and so on. This can be helpful if you want to send these notifications directly to stakeholders or resolution groups.

Typically, IT personnel will receive these notifications first, after which they can take the appropriate actions. To divide the workload and based on the complexity of the issue, different notifications can be sent to different layers of the IT department. You can consider the following division as a starting point:

• First and second level support: Receive issues that are repetitive and easy to fix, receive and action health reports
• Third level support: Fix complicated issues for which more knowledge of the solution and the business process is necessary

You can also consider involving business people in the support process and send them notifications directly from your monitoring products. As they have the business knowledge of the involved business processes, they will be aware of the consequences if anything goes wrong with an application/interface/solution. This would also take away the need to have the IT department inform business users of incidents.

Moving forward, you can also think of providing business people with read-only access to the Azure Portal, and/or other tooling related to the integrations, for analysis purposes. If the organization has matured enough and there is enough confidence in the tooling, you could even consider giving business people write access to the tooling, so they can fix certain issues themselves without the involvement of the IT department.