Alerting on /actuator/health on AKS

[RafaelF]

Good morning,

I'm looking to get some advice on alerting for (or without) /actuator/health requests on AKS.

Our naming rules for services are using namespace_workload_className, resulting often in having the actuator bundled together with other requests.

I've considered to mute them or modify naming rules to create a separate service, but honestly I'm not sure. I have been dragging and thinking about this topic for a while so I've decided to ask for some help.

• From my understanding, the main purpose of actuator is to do a low level technical health check and trigger a auto restart on failure, so you might as well alert on restarts and ignore these requests?
• How are you handling actuator on your environment?
• Are there benefits for alerting on other endpoints if you stop considering the actuator requests, Dynatrace today (with grails) already gives you alerts by endpoint even if you don't mark as key requests, right?

Appreciate your time.
Best regards,
Rafael

[sujit_k_singh]

Hi @RafaelF 

Should you alert on /actuator/health?No

You're right - the primary purpose o /actuator/health is just for K8s liveness/readiness probes — if it fails, the pod restarts automatically. Alerting on it just adds noise becasue

If the health check fails, Kubernetes restarts the pod automatically
Dynatrace already detects pod restarts and can alert on that
High failure rates on /actuator/health usually indicate an infrastructure issue that surfaces through other detections

What I'd recommend:

Request naming rules (Settings → Server-side service monitoring → Request naming) — Group /actuator/* under a separate request name so it doesn't pollute your business endpoint metrics and failure rates.
Failure detection rules — Optionally exclude actuator requests from error counting so they don't trigger service-level alerts.
Don't worry about missing pod issues — Dynatrace I already alerts on pod restarts and availability drops automatically, so you're covered without monitoring actuator.

And yes, with Grails, you already get endpoint-level anomaly detection without marking everything as key requests. Key requests are only needed for custom SLO thresholds.

Thanks,

Sujit

[RafaelF]

HI @sujit_k_singh 

Thanks for the reply!

Correct me If I'm wrong but to separate '/actuator/*' endpoint you have to modify service detection?

For example, using Service detection v1 (Service detection rules for Full Web Requests):

• IF URL path contains "/actuator/" - Change URL context root to "/actuator/*"
• And then include URL context root in the naming for uniqueness.

Is there a better way? Maybe using v2?

[sujit_k_singh]

Hi @RafaelF 

Two different things here:

Service detection rules — Split actuator into a separate service (what you described with URL context root). Works, but creates an extra service to manage — overkill for health probes.
Request naming rules — Groups actuator under a distinct request name within the same service. Simpler, less maintenance.
Your v1 approach works fine. v2 doesn't fundamentally change the logic, just the API format.

My recommendation: Use Request naming rules (Settings → Server-side service monitoring → Request naming) with condition "URL path contains /actuator/" and set a fixed name like [Actuator] Health Check. Achieves the same goal without creating extra services.

Thanks,

Sujit