Skip to content
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

[Alerting] Edit alert created on UPTIME UI #67252

Closed
enotspe opened this issue May 25, 2020 · 7 comments
Closed

[Alerting] Edit alert created on UPTIME UI #67252

enotspe opened this issue May 25, 2020 · 7 comments
Labels
Feature:Alerting Team:Uptime - DEPRECATED Synthetics & RUM sub-team of Application Observability

Comments

@enotspe
Copy link

enotspe commented May 25, 2020

It would be nice to be able to edit an alert that has been created from UPTIME UI. Furthermore, on alerted instances, it will be nice to see wich monitor.ids triggered the alert

image (3)
image (2)

@myasonik myasonik added Feature:Alerting Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams) Team:Uptime - DEPRECATED Synthetics & RUM sub-team of Application Observability labels May 26, 2020
@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-alerting-services (Team:Alerting Services)

@elasticmachine
Copy link
Contributor

Pinging @elastic/uptime (Team:uptime)

@mikecote
Copy link
Contributor

@elastic/uptime let us know if you need help with anything. I believe we've discussed this before but requiresAppContext is set to true here

which prevents these alert types from being editable.

@mikecote mikecote removed the Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams) label May 27, 2020
@justinkambic
Copy link
Contributor

@mikecote thanks - we're actually working on this right now, our changes will likely resolve this issue. The main challenge is our alert UI elements rely on some state that's only available today if our app mounts, we're hoping to make these services available at start time instead, which would make us ok to set requiresAppContext to false.

@shahzad31
Copy link
Contributor

@enotspe

Furthermore, on alerted instances, it will be nice to see wich monitor.ids triggered the alert

By this you means in the actual alert message monitor.id should be included? i think this should be possible even right now. What alert message are you getting right now? and how do you think it should be formatted?

@enotspe
Copy link
Author

enotspe commented May 28, 2020

No. I mean when you enter alert details, i see xpack.uptime.alert..... which does not give any info. I think we should be seeing all the monitor.ids that are down.

According to the documentation, these are called alert instances

https://user-images.githubusercontent.com/47488630/82771481-d988d280-9e01-11ea-9839-76074f0c75e5.png

@andrewvc
Copy link
Contributor

andrewvc commented Jun 3, 2020

Closing in favor of elastic/uptime#179

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature:Alerting Team:Uptime - DEPRECATED Synthetics & RUM sub-team of Application Observability
Projects
None yet
Development

No branches or pull requests

7 participants