[Feature Request] Notification will be sent only when service timeouts exceed N consecutive occurrences. about uptimeflare HOT 6 CLOSED

I'm trying to understand the code, but I need some time. But I am using Pythoner and still learning.

from uptimeflare.

Hello, actually I also encountered this problem (especially when accessing some domestic servers).

My current solution is to use the onIncident callback to detect whether an incident has been open for a certain amount of time (e.g. >3 minutes means 3 continuous failures) before sending a notification to prevent too many messages from being sent.

But I'd also be happy to implement a built-in “Grace period” to solve this problem: add an optional “Grace period” configuration to each monitor that ignores all incidents that last less than the Grace period (which may include not showing up on the WebUI, not counting in the over-all downtime calculation, not sending out messages, etc.)

from uptimeflare.

Additionally, I discovered today that using custom regions for detection significantly improves stability and reduces false triggers.

However, if no region is specified or if US nodes are used, false triggers become quite frequent. (In my project, I use nodes from the U.S., Japan, Hong Kong, and the Netherlands.)

And how to i use onIncident callback on my project?

from uptimeflare.

Additionally, I discovered today that using custom regions for detection significantly improves stability and reduces false triggers.

However, if no region is specified or if US nodes are used, false triggers become quite frequent. (In my project, I use nodes from the U.S., Japan, Hong Kong, and the Netherlands.)

And how to i use onIncident callback on my project?

The false positive is related to the connectivity of Cloudflare edge to your server by a number of complex factors including GFW, routing, distance, and more. So you may need to specify a region to reduce the number of false positives, which is normal.

onIncident is just a rougher workaround that I use myself, I may implement the grace period feature you proposed recently (although I won't give an ETA), you can wait and use the grace period feature directly to reduce the number of false positives.

from uptimeflare.

The false positive is related to the connectivity of Cloudflare edge to your server by a number of complex factors including GFW, routing, distance, and more. So you may need to specify a region to reduce the number of false positives, which is normal.

None of my servers are in China, and they all use the nearest Cloudflare nodes.

For example, Japan and Korea use Japan nodes, Hong Kong and Singapore use Hong Kong nodes, and the United States uses U.S. nodes. The latency is kept within 100ms, with some even within 10ms.

from uptimeflare.

A new way of notification has been implemented, along with the grace period, see the https://github.com/lyc8503/UptimeFlare/wiki/Setup-notification

from uptimeflare.