Review a diagnostic investigation
Open an App, select Diagnostics, then choose an investigation by its short identifier.
Confirm that you opened the right investigation
Section titled “Confirm that you opened the right investigation”Match the description and creation time to the incident, deploy, or symptom you are reviewing. Record the investigation identifier before making a change so you can preserve the relationship between the report and your verification.
The Diagnostics list is newest-first and shows 20 records at a time. Use Previous and Next when the relevant investigation is older.
The Request investigation control is currently disabled. On-demand investigations are coming later; the current list contains automatically created investigations.
Follow investigation status
Section titled “Follow investigation status”| Status | What to do |
|---|---|
| In progress | Wait for more report content; the page refreshes every 5 seconds. |
| Running | Diagnostic work continues; the page refreshes every 5 seconds. |
| Completed | Review the evidence and act only after confirming current state. |
| Failed | Preserve the identifier and contact support. |
| Unknown | Treat the status as unresolved and contact support if it persists. |
The metadata panel also shows severity, the created time, and the completed time once processing has ended.
A report can show No findings yet in any status, including Completed and Failed. While processing is in progress, it means results haven’t been produced or exposed yet. On a completed report, it means the report holds no customer-visible finding. Neither state is an all-clear. Automatic refresh stops after completion or failure.
Read the report in order
Section titled “Read the report in order”- Status and timestamps: establish when the evidence was gathered and whether processing finished.
- Severity: understand the potential impact, not the certainty.
- Summary: identify the redacted description of the observed state.
- Findings: expand each relevant finding.
- Finding details: per-finding evidence text, suggested actions, and code references aren’t reliably shown on the current page. Don’t treat their absence as evidence that no code or configuration cause exists.
Metrics, logs, events, deploy history, and code context are different evidence sources. A finding can use one without the others. Missing corroboration should reduce how strongly you rely on the recommendation.
When a request trace exists for the same evidence window, open it from the
Diagnostics trace list by matching its HTTP method and request URL. Then
compare the finding against the ranked attributable hotspots and their source
spans in the waterfall. Inclusive waits such as varnish.backend_fetch keep their full elapsed
duration in the waterfall, but rank only on the remainder that isn’t downstream work;
the same applies to a proxy’s reported wait on its upstream. If the panel reports a
large Unattributed figure, the time is real but was spent in code the trace doesn’t
instrument, so the hotspots alone won’t explain it.
The waterfall is request evidence, not the investigation itself: it can confirm
where time was spent but doesn’t prove root cause. Preserve the trace ID with
the investigation ID in your incident notes.
Separate severity from confidence
Section titled “Separate severity from confidence”Severity describes potential customer or operational impact. Confidence describes how strongly the evidence supports the finding. The current page can show confidence as a numeric value.
Don’t treat a confidence value as authorization to make a destructive change. Don’t dismiss a high-severity issue only because the finding is preliminary. Use the evidence, current App behavior, and business impact together.
Check whether the report is stale
Section titled “Check whether the report is stale”A completed report doesn’t update after the App changes. Before acting:
- compare the report times with the latest deploy, rollback, restore, resize, configuration change, or credential rotation;
- confirm that the original customer-visible symptom still occurs;
- verify that any code reference supplied through the report or support belongs to the currently deployed revision;
- check current Usage and relevant operation status;
- treat missing or degraded current data as unknown, not as recovery.
If the App changed after the report completed, use the report as historical context. Don’t assume its recommendation still applies unchanged.
Apply one safe correction
Section titled “Apply one safe correction”- Choose the narrowest action that addresses the supported finding.
- Review rollback and data consequences before a deploy, restore, or configuration change.
- Verify a current backup before a change that can alter customer data.
- Apply the change through the normal portal, Git, or CLI workflow.
- Test the original failing path and one adjacent critical path.
- Review current deploy, Usage, and Diagnostics state for immediate recurrence.
- Record the action, time, result, and investigation identifier.
The report doesn’t apply code, configuration, data, or resource changes for you. Several unrelated changes at once destroy the evidence needed to know which correction worked.
Distinguish a load error from a failed investigation
Section titled “Distinguish a load error from a failed investigation”Failed to load investigation means the portal couldn’t retrieve the report. Select Retry. If it persists, include the displayed error and investigation identifier in a support request.
Something went wrong means the diagnostics view failed to render. Select Try again and include the displayed error ID if the failure repeats.
A Failed status means diagnostic processing ended without a completed report. Include the App ID, investigation identifier, incident start time and time zone, customer impact, relevant deploy identifier, and any safe containment already applied. Include any displayed error ID.
Never include passwords, private keys, API tokens, raw secret values, payment data, or unredacted customer records. See Get support or Respond to an App incident.