Diagnosing High Response Time Alerts in Dynatrace for Microservices

Recognizable condition

Dynatrace opens a problem card when a service’s average response time exceeds the configured threshold (for example, >2 seconds) for five consecutive minutes.

Cause‑symptom table

Ordered diagnostic checks

1. Open the service overview page for and view the CPU and memory usage charts. Look for sustained CPU >80 % or memory pressure.
2. Navigate to the Thread pools section (or process‑level thread metrics) and check if the active thread count is near the configured maximum and if the queued count is rising.
3. In the service flow view, select the outgoing calls to downstream services and examine the average call time and percentile (e.g., p95) for the last 10 minutes.
4. Check the GC activity under the process details: GC pause time, GC count, and heap usage trends.
5. Open the request attributes or purepath breakdown and review the request size distribution (average size, max size) for the same time window.

Fixes tied to findings

• If CPU saturation is observed – consider horizontal scaling (add instances) or profile hot methods to reduce CPU‑intensive work.
• If thread‑pool exhaustion is seen – increase the pool size in the application configuration or switch to asynchronous processing where appropriate.
• If downstream latency is high – investigate the dependency (check its own Dynatrace metrics), add a circuit‑breaker, or implement request‑level timeout/retry policies.
• If GC pressure is evident – tune the JVM heap size, adjust GC algorithm, or reduce object churn by optimizing allocation patterns.
• If large payloads are the driver – enable response/request compression (e.g., GZIP) or paginate/filter data to reduce transferred bytes.

Escalation criteria

Escalate to the platform or SRE team when:

• Applied remediation does not bring the response time back below the threshold after 15 minutes of observation.
• The problem affects multiple services simultaneously, suggesting a shared infrastructure issue.
• The alert triggers an SLA breach or impacts business‑critical transactions.

Verification steps

1. Reproduce the load pattern in a staging environment and confirm that Dynatrace creates a problem matching the condition described.
2. After applying a fix, monitor the specific metric you addressed (CPU, thread‑pool usage, downstream latency, GC pause, or request size) to verify it returns to normal levels.
3. Ensure the problem card closes automatically and that no related alerts persist for the affected service.