Zdx Analyze Application Health

zdx_list_applications()```text
Optionally filter by location, department, or geolocation:
```textzdx_list_applications(  location_id=["<location_id>"],  department_id=["<department_id>"],  since=4)```text
**Categorize results by score:**
- **Good (66-100):** Healthy, no action needed- **Okay (34-65):** Degraded, investigate further- **Poor (0-33):** Critical, immediate attention
---
### Step 2: Investigate Degraded Applications
For each application with a degraded or poor score, get the score trend to understand if this is a new or ongoing issue.
```textzdx_get_application_score_trend(  app_id="<app_id>",  since=24)```text
**Interpret the trend:**
- **Sudden drop:** Likely an incident (server, network, or ISP issue)- **Gradual decline:** Resource exhaustion, growing user base, or config drift- **Intermittent spikes:** Unstable network path or periodic load spikes
Get application details for additional context:
```textzdx_get_application(app_id="<app_id>")```text
---
### Step 3: Drill Into Metrics
For each degraded application, check individual metrics to isolate the bottleneck.
**Page Fetch Time (overall web performance):**
```textzdx_get_application_metric(  app_id="<app_id>",  metric_name="pft")```text
**DNS Resolution Time:**
```textzdx_get_application_metric(  app_id="<app_id>",  metric_name="dns")```text
**Availability:**
```textzdx_get_application_metric(  app_id="<app_id>",  metric_name="availability")```text
**Metric interpretation guide:**
| Metric | What It Measures | Healthy | Degraded | Critical ||---|---|---|---|---|| `pft` | Page Fetch Time (full load) | < 3s | 3-8s | > 8s || `dns` | DNS resolution | < 50ms | 50-200ms | > 200ms || `availability` | App reachability | 99-100% | 95-99% | < 95% |
**Bottleneck mapping:**
- High `pft` + normal `dns` + high `availability` → Server or CDN slow- High `pft` + high `dns` + high `availability` → DNS resolution issues- Low `availability` → Application or network unreachable
---
### Step 4: Identify Impacted Users
For each degraded application, list the impacted users.
**Users with poor scores:**
```textzdx_list_application_users(  app_id="<app_id>",  score_bucket="poor")```text
**Users with okay scores (borderline):**
```textzdx_list_application_users(  app_id="<app_id>",  score_bucket="okay")```text
**Filter by location to scope the impact:**
```textzdx_list_application_users(  app_id="<app_id>",  score_bucket="poor",  location_id=["<location_id>"])```text
**For a specific user, get detailed experience data:**
```textzdx_get_application_user(  app_id="<app_id>",  user_id="<user_id>")```text
---
### Step 5: Cross-Reference with Alerts
Check if any active alerts correlate with the degraded applications.
```textzdx_list_alerts(since=24)```text
For relevant alerts:
```textzdx_get_alert(alert_id="<alert_id>")zdx_list_alert_affected_devices(alert_id="<alert_id>")```text
---
### Step 6: Present Application Health Report
Assemble the `__ZDX_DATA__` payload defined in the *Data Payload Contract* and render it through `./templates/report.html.template` (see the **HTML OUTPUT** section). The template already produces the application table, KPI cards, color coding, search/sort, and CSV export — do **not** hand-author any HTML or markdown table here.
What you DO write is the `analysis` block inside the payload. **Do not skip it.** This is what makes the report useful:
- **`analysis.summary`** (3–5 sentences): overall health posture — how many apps are good vs. okay vs. poor, the dominant bottleneck pattern across degraded apps, and whether this is a localized or organization-wide degradation.- **`analysis.rootCause`** (1–3 sentences per degraded app): state the primary bottleneck metric and what it indicates (e.g., "Microsoft 365 PFT at 12.4s indicates server-side or CDN latency, not DNS or network"). Quote the numbers from the metric calls in Steps 2–3.- **`analysis.remediation`** (4–6 items): label each with a priority bucket and a concrete action.
| Priority | Apply to | Action ||---|---|---|| `Immediate` | Apps with score 0–33 | Check service health dashboards, ISP paths, and Zscaler cloud path. Engage the application vendor if server-side. || `Investigate` | Apps with score 34–65 | If declining, drill into the bottleneck metric. If stable, suspect a capacity or configuration issue. || `Monitor` | Borderline apps (score 66–70) | Proactive monitoring. No action unless score drops below 66 within 24h. || `Communicate` | Apps with the highest user impact | Notify affected user list; route to the application team with the metric evidence. |
---
## Filtering Strategies
### By Location
Useful for investigating office-specific issues.
```textzdx_list_applications(location_id=["<location_id>"])zdx_get_application_score_trend(app_id="<app_id>", location_id=["<location_id>"])zdx_get_application_metric(app_id="<app_id>", metric_name="pft", location_id=["<location_id>"])```text
### By Department
Useful for understanding impact on specific business units.
```textzdx_list_applications(department_id=["<dept_id>"])zdx_list_application_users(app_id="<app_id>", department_id=["<dept_id>"])```text
### By Geolocation
Useful for regional analysis.
```textzdx_list_applications(geo_id=["<geo_id>"])```text
### By Time Window
Adjust `since` (hours) for different investigation windows:
- `since=2` -- current issues (default)- `since=4` -- recent trends- `since=24` -- daily overview- `since=168` -- weekly review
---
## Edge Cases
### No Degraded Applications
```textAll 12 monitored applications are healthy (score > 66).
Top performers:1. GitHub (94)2. Zoom (92)3. Box (91)
No action required. Consider reviewing alert thresholdsif you want earlier notification of potential issues.```text
### All Applications Degraded
If most applications show poor scores simultaneously:
- Likely a network-wide or ISP issue, not application-specific- Check ZDX alerts for ISP or network incidents- Compare across locations to see if it's localized or global
### Single User Reports Issue but Scores Are Good
If the application score is healthy org-wide but one user reports issues:
- Use `zdx_get_application_user(app_id, user_id)` for user-specific data- Switch to the **Troubleshoot User Experience** skill for individual investigation
---
## Quick Reference
**Primary workflow:** List Apps → Identify Degraded → Check Trends → Drill Into Metrics → List Impacted Users → Cross-Reference Alerts → Report
**Tools used:**
- `zdx_list_applications()` -- list all monitored apps with scores- `zdx_get_application(app_id)` -- application details- `zdx_get_application_score_trend(app_id)` -- score over time- `zdx_get_application_metric(app_id, metric_name)` -- pft, dns, availability- `zdx_list_application_users(app_id, score_bucket)` -- impacted users- `zdx_get_application_user(app_id, user_id)` -- per-user detail- `zdx_list_alerts(since)` -- correlated alerts- `zdx_get_alert(alert_id)` -- alert details- `zdx_list_alert_affected_devices(alert_id)` -- alert scope
**Score buckets:**
- `good`: 66-100- `okay`: 34-65- `poor`: 0-33
**Metric names:** `pft`, `dns`, `availability`
**Related skills:**
- [Troubleshoot User Experience](../troubleshoot-user-experience/) -- for individual user investigation- [Investigate Alerts](../investigate-alerts/) -- for alert-focused investigation- [Compare Location Experience](../compare-location-experience/) -- for cross-location analysis