Under an ITIL point of view, a service outage not detected by the customer, is not an incident. But, being more pragamatic the easiest way is to consider them incidents. But you must maintain a differentiation between an estandard incident and a monitoring incident.
After this introduction, this is my recommendation:
It depends. If you can identify the customer, and you want to be clear to him (reporting him all events), use this customer as the incident customer. But, select as service type: "CI Outage" or "Monitoring Event", not "Service Restoration".
If you can't identify the customer (I mean the exact person), then create a virtual customer for the monitoring tool and use it as the customer.
If the actual customer calls your service desk, create a new incident and mark it as a duplicate.
At the end the most important is to differentiate between normal incidents and monitoring events.
Thanks Jose, So from an ITIL perspective should it be a Problem? I was thinking that we would create a service account user, and make sure the reported source is "Automation".
Any other thougths, from a blue sky perspective?
No. A problem is a situation that generates incidents. But not in this case. A problem can be a software bug.
An incident is a reduction in the service level that the user is receiving. A night hang of a server, restored before any customer notices it, is not an incident. But this clarification of incident is only under a service level point of view. If you have an SLA or you report your service level to the client, then it is very importan. For the support staff, it is almost the same.
That's the reason to tell you to differentiate between both sitations. Because a system going down, and restored before the client notices it, can be a good indicator of your support service.
I will not use the source as the differentiation field, since you can have monitoring events and incidents coming from diverse sources. For instance:
- An admin detects a bad situation, opens an incident and it is resolved before the customer notices it. This is not an incident, is an event resolved before comming into an incident.
- A monitoring tool detects that the email server is down. This is an incident. A mail may come and the user was not notified. So the service recieved by the user was degradated.
See the difference? The question is: Is the service degradated? Did the received service level by the customer reduce? If the answer is yes, then you have an incident.
But this definition of incident is my interpretation as an ITIL v3 Service Expert. At the end, this interpretation must be agreed with the customer. But almost every customer will agree to not consider an incident, in SLA terms, some situation that has not degraded the received service.
As before you reply is greatly appreciated. Lets assume that we want to log issues that we have found (not customer reported). In that case we create an incident, but the firstname and lastname are required fields. Is it possible to create an incident without firstname and lastname?
Under an ITIL point of view, the resolution of the issues must be confirmed by the "customer". In those cases I recommed to select the technic os system that discovered the issue as a virtual "customer". That allows you to better determine the source. Also is the source is a person, allows you to follow the ITIL recommendation and let the technic to confirm the correct resolution.
For monitoring system I create users where the first name is "System" and the last Name is the name of the System.