We are discussing this issue, where a surveillance application creates tickets when the available Space on a disk reaches a certain level.

Would you Guys have this issue create Incidents, og Service requests?

One says, that it potentially could interrupt a service, (eg. if the disk runs full) and therefore should be created as an incident
another says that it isn't an incident until the service is actually interrupted, Thus these warnings should be handled as requests for Service (Administration (HPSM) )

ITIL Incidnet definition:-
An unplanned interruption to an IT Service or reduction in the quality of an IT service. Failure of a configuration item that has not yet affected service is also an incident — for example, a reduction in disk capacity.

ITIL Incidnet definition:-
An unplanned interruption to an IT Service or reduction in the quality of an IT service. Failure of a configuration item that has not yet affected service is also an incident — for example, a reduction in disk capacity.

Hi KOS thanks for commenting.

I actually got to the same conclusion earlier on. however we do not have event management (yet).
We are at a pretty early state of implementing ITIL. so we make due with what we have:-)
My suggestion was to handle these alerts as requests for Administration (HP Service Manager) mainly because I think it to be the least wrong, of the two.
my beef with handling this as incidents is that statstics show that we have X (could be around 3000 per year) incidents each year, that are not really incidents. but it would seem that our IT-department has more incidents than it really has (In this aspect I regards Incidents to be worse than Service requests)

Hi Lynhe, as long as these are being managed appropriately then it doesn't really matter if you define it as an incident, service request or event. If you're worried about this affecting your stats, you could create a separate category that can be excluded from reports when carrying out analysis?

That's what we do now.. they have a certain fixed text string in the description, which enables me to exclude these, from certain reports...
I think we'll stick with this, as developing a new webservice for creating Requests instead will be quite expensive, compared to the actual value for us:-)

However, the discussion started, when I stated (being the new, and unexperienced, Incident Manager) that these cases were not incidents. as they were not unplanned.

I said:
When you set an alarm to go off at a certain point, knowing that it will actually go off but not when. then it is planned. (knowing there is a rise in disk space used)

one of the arguments against this was:
If a customer/client orders a server with a certain capacity, stating that this is enough for lifetime use of this server/service. and the alarm still goes off, then it's an incident... because it wasn't expected (Planned)

I think there is maybe a difference here between something that is expected and something that is planned. You are expecting the capacity issues hence the monitoring is in place, but you can't say exactly when it will occur.

If it's planned and there is no risk of impact to the customer, then the monitoring isn't needed.

If I were managing this service I would want to see the patterns and trends over time so that if the customer's spec needed to be changed, I could go have that discussion with them before the service was affected.

So again it's sort of semantics but the important thing is that it's being managed.

From experience disk space capacity warnings were treated as alerts as a result of a predefined threshold being exceeded. The alert would generate a ticket that would automatically be forwarded to the appropriate support team to act upon in order that the alert doesn’t cause an incident._________________Change & Project Management