Is your feature request related to a problem? Please describe.
The topology map gives no quick visual answer to "which services are having issues right now". Alerts are correlated to services (alert.service == TopologyService.service) and shown as "N alerts" badges, but every node looks the same otherwise — you have to read badges one by one to spot the services affected by a firing incident.
Describe the solution you'd like
Color the service node border by the highest severity of the service's firing alerts:
- red — firing critical / high / error
- orange — firing warning
- default gray — no firing alerts
plus a small legend on the map. Resolved/suppressed alerts should not affect the color.
This is how service topology dashboards commonly visualize state (e.g. the open-source dephealth-ui renders ok/degraded/down node states), and Keep already has all the data client-side.
Describe alternatives you've considered
- Using incident data only (too coarse: incidents exist per application).
- Coloring node headers/backgrounds — noisier; a border keeps the map readable.
Additional context
Prototype verified on a self-hosted lab stand (17-service topology, real firing/resolved alert cycle) — screenshots:
Before (firing critical alerts on two services, all nodes look the same):
After (red borders on the affected services + legend):
Is your feature request related to a problem? Please describe.
The topology map gives no quick visual answer to "which services are having issues right now". Alerts are correlated to services (
alert.service == TopologyService.service) and shown as "N alerts" badges, but every node looks the same otherwise — you have to read badges one by one to spot the services affected by a firing incident.Describe the solution you'd like
Color the service node border by the highest severity of the service's firing alerts:
plus a small legend on the map. Resolved/suppressed alerts should not affect the color.
This is how service topology dashboards commonly visualize state (e.g. the open-source dephealth-ui renders ok/degraded/down node states), and Keep already has all the data client-side.
Describe alternatives you've considered
Additional context
Prototype verified on a self-hosted lab stand (17-service topology, real firing/resolved alert cycle) — screenshots:
Before (firing critical alerts on two services, all nodes look the same):
After (red borders on the affected services + legend):
