Open Darkvater opened 2 years ago
TwiN
commented
2 years ago f899f41d161e675039168b196aa28304f648f0af has added [ENDPOINT_URL] and [ENDPOINT_GROUP], but as for the other suggestions you had, I'm not sure how to tackle them.
Honestly, I would rather have a specific provider implementation for more complex use cases, but if you have a solution, feel free to suggest it.
TwiN
commented
2 years ago The aforementioned [ENDPOINT_URL] and [ENDPOINT_GROUP] have been released in v4.0.0.
stendler
commented
4 months ago What about a [DEFAULT_DESCRIPTION] for the conditions? The other providers all have similar descriptions hard coded that list the conditions and their status with emojis and a bit of text. A method returning that default description string could even be added to the provider interface for other provider implementations to reuse, if they don't add anything special?
Also, nice to have would be [GATUS_URL] to link to the status page - but I suspect gatus does not know this itself?
Based on that, [GATUS_ENDPOINT_URL] would link to the gatus endpoint page. This contains the endpoint group and name, but in lowercase and url-ified, thus [ENDPOINT_URL] and [ENDPOINT_GROUP] cannot be used directly.
TwiN
commented
4 months ago Having an option to specify Gatus' URL would certainly be beneficial, as it could make alerts point to the status page directly.
Describe the feature request
Alerting currently only has the below placeholders.
This is quite rudimentary to implement into custom alerting endpoints (like rocket.chat webhooks for example). While some of the built-in alerts can show how often the health-point failed, or show which condition failed, this is not possible for custom alerts. I think the following placeholders should be added:
I am not sure what the final architectural design is for alerting but it should be made easy to add any alerting types. For this we could think about the ability to execute external scripts (passing placeholders to it) and offload maintenance and development of it to the community
Why do you personally want this feature to be implemented?
Powerful alerting capabilities are a must for any monitoring tool. Nobody is going to be looking at a web page all day long to see if, and when something fails. Potentially off-loading alerting development/maintenance to the community encourages wider adoption and more focus on project's main aims.
How long have you been using this project?
1 week
Additional information
Love the project by the way! Was a breeze to setup, a well-thought out, easily understandable UI, and minimal resource requirements make it perfect for use outside of a kubernetes/managed cloud environment.