Application Network

The Network tab in Discover Applications shows the health of every outbound API call your app makes. It surfaces error rates, latency percentiles (p50, p95, p99), and request volume per endpoint — broken down by HTTP method and URL pattern — so you can spot degraded routes before users report them.

Accessing Network Monitoring

1. Navigate to Discover > Applications in Last9.
2. Select your application.
3. Click the Network tab.
4. Choose your environment from the top filters.
5. Set the time range with the date picker.

Endpoint Table

The table lists every outbound API endpoint observed in the selected window, sorted by error rate (highest first) by default so degraded endpoints surface immediately.

Column	Description
Health	Color-coded badge: healthy / degraded / critical
Endpoint	HTTP method chip (color-coded) + URL pattern, e.g. GET /api/v2/portfolio
Requests	Total request count in the window
Error Rate	Percentage of requests that failed: HTTP 4xx/5xx, no response at all (status 0, shown as Failed / no response), or a GraphQL operation that returned a logical error (STATUS_CODE_ERROR) despite an HTTP 200
p50	Median response time for successful (2xx) requests
p95	95th-percentile response time for successful requests
p99	99th-percentile response time for successful requests

Click any column header to re-sort. WebSocket connections (HTTP 101) are automatically excluded — they are long-lived spans and would skew p95 values into the tens of seconds. A footnote below the table indicates how many WebSocket connections were excluded.

Health badge thresholds

Badge	Condition
Healthy (green)	Error rate < 1% and p95 < 1,000 ms
Degraded (amber)	Error rate 1–5% or p95 1,000–3,000 ms
Critical (red)	Error rate > 5% or p95 > 3,000 ms

A single failing condition is enough to move an endpoint to the next severity level. Fix the most critical endpoints first — the default sort surfaces them at the top.

HTTP method color coding

GET badges are blue, POST green, PUT amber, DELETE red. The badge carries the method label and is part of the Endpoint cell, not a separate column, so you can scan method and path together.

GraphQL operation breakdown

When your app sends GraphQL requests, Last9 records the operation name alongside the URL. The table shows a separate row per GraphQL operation (e.g. POST /graphql — GetPortfolio, POST /graphql — UpdateOrder) rather than collapsing all GraphQL traffic under a single /graphql row. This lets you identify which operation is slow or failing without parsing raw traces.

If GraphQL operation names are not appearing, confirm that your RUM SDK is configured to record the graphql.operation.name attribute and that the relevant span name is not excluded by a URL exclusion pattern.

Endpoint detail panel

Click any row to open the detail panel without leaving the table. The panel shows:

• 5 stat tiles: Total requests, error count, error rate (count / total), p95, p99.
• Error rate sparkline: Error rate over the selected window, sampled at ~24 data points. The sparkline is loaded on panel open, not in advance.
• View affected sessions button: Applies an endpoint = <span_name> filter and switches to the Sessions tab, where you can inspect individual user sessions that hit this endpoint.
• Copy PromQL button: Copies the underlying PromQL query to the clipboard (icon switches to a checkmark for 2 seconds to confirm).

Close the panel by clicking elsewhere in the table or pressing Escape. The panel is non-blocking — you can scroll the table while it is open.

Time range and filters

The time range picker controls the window used for all endpoint metrics. Narrowing the range reduces the window used in each gauge aggregation; windows shorter than 5 minutes may return sparse results for low-traffic endpoints.

The environment filter at the top of the Applications view applies globally to the Network tab. Network metrics are scoped by application, environment, and time range, and aggregate across app versions — comparing endpoint health between versions is not currently supported here.

Navigate to traces and sessions

From the endpoint detail panel, View affected sessions adds the endpoint as a filter in the Sessions tab. From a session’s detail view, you can open the correlated trace to see the full request waterfall for a specific failing request.

For direct trace queries, use the Traces Explorer with a span_name = "METHOD /path" filter and the same time window.

---

Troubleshooting

• No data appears in the Network tab

  Confirm that your RUM SDK is initialized and that network instrumentation is enabled. For web, the JS SDK auto-instruments XMLHttpRequest and fetch. For mobile, see the network phase spans configuration in Android, iOS, React Native, or Flutter.

• All endpoints show 0% error rate but users report failures

  The Network tab counts HTTP 4xx/5xx responses, requests with no response (status 0, shown as Failed / no response), and GraphQL operations with a logical STATUS_CODE_ERROR even on an HTTP 200. If none of these match the failures users report, check the Errors/Crashes tab for client-side exceptions that never produced a network request.

• GraphQL operations are collapsed into a single row

  The RUM SDK must record graphql.operation.name on the span. Check your SDK version and GraphQL instrumentation config.

• WebSocket connections skew the endpoint list

  WebSocket spans (HTTP 101) are excluded automatically. If you see a footnote counting excluded connections, this is expected behavior.

Please get in touch with us on Discord or Email if you have any questions.