@kylebrandt / @captncraig could you please review this pull request

Hey @kylebrandt, @captncraig!
Any objections to this change? Is there something else we need to implement before this gets merged?
Thanks,
Anna

Probably need @captncraig to review the behavior on this one.

In terms of how the default behavior was supposed to go in my head, at least in regard to emails:

• DelayedClose means "I'm pretty sure I have fixed the incident because I did x, y, z." The notification happens then because that is what other people (at least in my story I constructed :-/) need to know - the things has probably been dealt with and the monitoring system just needs to catch up.
• From there, you can just assume it is closed, if the problem still exists after the close duration then a new incident will be created

At least one problem with the story is that notifications (at least how I have constructed them) don't give you any information about the previous incident on the same alertkey. So it the person getting the new incident might not know about the previous one.

I'm okay customizing this behavior I'm just worried about changing default behavior here and maybe adding some complexity. Basically the falls under the idea that "less notifications are better" - but if @captncraig thinks the complexity is fine I'm okay with being able to customize this behavior.

@captncraig could you please share your thoughts on this?

@tdinucci, @muffix We are using this change more than 1 year already. Can you please review this MR?

@svagner we will consider but as no test coverage cannot accept as it stands

@tdinucci , I agree there is really required some amount of tests. I'll make tests then:) Thanks!

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.