-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Subscribers receive too much emails #2316
Comments
This is really by design. The more configurability we add, the harder the implementation becomes to maintain and for the user to manage their preferences. |
I understand. However, isn't the trade-off between "not updating the component" and "not knowing the component was confirmed" a bit hard to make? In other words, to eliminate email spamming we have to let user wonder whether "the component status is accurate", or if "the watchdog that updates it stopped functioning"... For users counting on the cachet page to accurately reflect the reality of SaaS nodes, being able to make the difference between "node is operational as of xyz" and "component status wasn't updated since xyz" is somewhat important. |
How about, we add a |
That would be perfect. Then the solution becomes: get the current component status from cachet, if the status changed update with silent to false, otherwise update ("confirm the state") with silent to true. |
The context is:
A cachet page that monitors the state of a service.
The service availability is verified every 10 minutes, and the cachet component is updated with the value.
Subscribers want to be warned whenever the service changes state.
Currently, the user is warned whenever the component state is updated, regardless of the value.
Solution: send notification email only when new information is available (for example: the component state is updated with a different status than the current one).
Workaround: update the component only when the value has actually changed. The problem with this is that the person looking at the component has no way of knowing the state of the service was actually monitored.
The text was updated successfully, but these errors were encountered: