Can you explain your “ticket” use case? Is it in relation to Openticket or do you have a notification rule set to directly create tickets?

Are you looking at “forcing” notification regardless of your resource status?

Or is this a matter of notification being sent only when a hard state is reached?

We do not use Openticket, we just use notifications rule (email) to create a ticket to our ticketing system.

Yes - exactly, I would like to have a option to force notification so that it will ignore what is configured as first notification delay to the host/service and it does not have reach the hard state.

I’m not sure how i can see a use to “force notification”, isn’t the “force check” enough in that case ?

Force check is not generating a alarm, it just forces quicker check.

I can give you an example:

Usually firewalls generate a ticket/alarm after they have been down for 15min. 

We receive a call from customer that nothing is working and firewall does not have any lights on (device is dead) and at the same time we see in our monitoring that device has been down only 5 min. With the one-click-alarm button I could generate an alarm/ticket right away and I down have to wait 10 more minutes for the system to generate a ticket or waist time manually creating the ticket in ticketing system.

​@katska I see what you mean with that use case, but in here then the issue has been raised manually by your user, not by the platform, so the ticket should have been made outside of the use of the platform, directly on the ticket system.

Maybe i don’t see this correctly, but meaning to create a ticket from the centreon platform early on as a third party raised a concern regarding an equipement feels like a workaround of the features of centreon.

Only my opinion.

I think we shouldn't focus on the word "ticket" in Katska's example.
I agree with her idea of forcing a notification regardless of the resource's status (soft-hard) and notification delay configuration (firstime, resent, ...).