'RESOLVED' email notification is sent out when the issue is not resolved

[jinghuiyin]

The RESOLVED email seems a false message. The issue was not resolved.

Also, it seems like RESOLVED and OPEN emails always come in pair. At about the same time RESOLVED is followed by OPEN. I have attached the screenshot.

Did anybody have this issue before? How can we fix it?

Thanks!

[kalle_lahtinen]

It looks like the same problem ID is being reopened. Are you sure that you have the pairs marked correctly in the picture? Meaning, what if 1:06 PM is actually the Open time and 1:23 PM is the Resolved time. And then it was reopened again right away at 1:24 PM. If that is the case, Resolved did not come before Open. Are these custom events btw?

[jinghuiyin]

Thanks for replying.

The alert is triggered by this synthetic monitor(please see attached), we have post-execution-script to check the results. If the result is (-1:0), then api.fail("XXXX Error: No responses received"). And during 11:46-12:06 period, it has remained as api.fail("XXXX Error: No responses received"). because the results keep the same, (-1:0). So why was the RESOLVED email sent when the issue remains the same?  Attached please find the OPEN and RESOLVED emails.

Thanks!

[jinghuiyin]

Here is another similar example. Please see attached. During the period time, the availability has been down the whole time.

[jinghuiyin]

Forgot to attach the screenshot for the above reply. Thanks!

[kalle_lahtinen · Accepted solution]

Hi,

You are executing that test with a pretty tight schedule, once per minute. Are you certain that during the times the bar is red, it hasn't successfully executed at least once (which would explain the Resolved event)? I'm not sure how the UI would show a case where a 30 minute segment contains 29 failed executions and 1 successful one - maybe it still shows as fully red.

When looking at this latest screenshot, it shows a 2,5 hour time window with a fully red bar. But the availability is 3,95 %, not zero. So my guess is that during the Resolved events we are getting 1 successful execution, and after that it starts failing again.

Overall it looks like the synthetic test should be made more reliable. Unless you are on purpose testing for failures here, it doesn't seem to add much value if it fails about 96 times out of 100.