# Application Network

> Monitor per-endpoint health — error rates, latency percentiles, and request volume — for every API call your app makes.

Source: https://last9.io/docs/discover-applications-network/

The **Network** tab in [Discover Applications](https://app.last9.io/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](https://app.last9.io/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](/docs/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](/docs/real-user-monitoring/android/), [iOS](/docs/real-user-monitoring/ios/), [React Native](/docs/real-user-monitoring/react-native/), or [Flutter](/docs/real-user-monitoring/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](https://discord.com/invite/Q3p2EEucx9) or [Email](mailto:support@last9.io) if you have any questions.