List recent requests from Application Insights with duration, result code, and success flag, then take an operation ID into the exception and span views.
pks otel traces [APP] [options]$ pks otel tracesLast hour of requests
$ pks otel traces --has-error --since 24hFailed requests over the last day
$ pks otel traces my-app --limit 50Fifty most recent requests for one app
$ pks otel traces --format JsonMachine-readable output for jq
pks otel traces queries the requests table in Azure Application Insights — one row per inbound request, with duration, result code, and a success flag. It answers "which endpoint is slow or failing", and it is where you pick up the operation ID that the other three commands consume.
pks appinsights init — stores the App ID this command queries. Without it, the command warns and exits with code 1.pks foundry init — establishes the Azure AD identity used to obtain the query token.pks otel traces
You get up to 20 requests from the last hour. The status column renders a green check or a red cross derived from the success field, alongside the result code and duration.
pks otel traces --has-error --since 24h
--has-error adds success == false to the query. Without the flag, successful and failed requests are both returned, which is what you want when you are hunting latency rather than errors.
pks otel traces my-app --since 7d --limit 50
The positional argument filters on the application name. --since accepts a number with a d, h, or m suffix; anything else silently falls back to one hour.
Copy the operation ID from a failing row and use it as the pivot into the other views.
pks otel errors --operation-id abc123
pks otel spans --operation-id abc123
pks otel logs --trace-id abc123
Because table output shortens long values, take the ID from JSON when the exact-match filters return nothing.
pks otel traces --has-error --format Json
JSON mode exposes both Success and a separate HasError field, which is Success inverted. Field names are PascalCase, matching the underlying C# model, not the lowercase KQL column names. It is written compact to standard output with no terminal markup, so it pipes into jq directly.
pks otel traces --since 24h
You should see a table of requests with a status column. If you see Application Insights is not configured. instead, complete step 1.
| Flag | Default | Description |
|---|---|---|
--since <DURATION> | 1h | Time window, such as 1h, 6h, 24h, or 7d. |
--limit <COUNT> | 20 | Maximum rows returned. |
--format <FORMAT> | Table | Output format: Table or Json. |
--has-error | — | Return only requests where success is false. |
--verbose, -v | — | Accepted for consistency with the group, but this command never reads it. No effect. |
The positional APP argument is optional and filters on the application name.
-v prints nothing extra. — expected. Only pks otel errors implements the verbose query dump. Use that command to inspect the generated KQL.
Everything looks healthy but users report errors. — a request can succeed at the HTTP layer while an outbound call fails. Check pks otel spans for the operation ID.
No rows at all. — the app-name argument matches the cloud_RoleName dimension exactly. Drop the argument to confirm telemetry is arriving at all.