Launch GraphOS Studio

Operation metrics in GraphOS

Understand your operation metrics, including request rate and latency


The retention period for metrics depends on your plan. Refer to the pricing page for details.

Once you've configured your graph to send operation metrics to GraphOS, you can view them in GraphOS Studio from any 's Insights page:

The Insights page in GraphOS Studio

This page combines and metrics and has two main sections:

When you click an from the left sidebar or overview, this view shows detailed information about the individual .

The Insights page in GraphOS Studio

You can always return to the overall view by clicking Overview on the left sidebar.

Operations overview

The Operations Overview is top and center because it summarizes your 's recent usage and performance. It includes the median, range, and percentage change for:

  • The rate of requests sent to your
  • Your 's p95 service time
  • Your 's error percentage

Beneath each of those metrics, you can also see the individual s with:

  • The highest request rates
  • The slowest p95 service time
  • The highest error percentage
Operations Overview in GraphOS Studio


The blue M icon beside an indicates it's a .

The purple S icon beside an indicates it's a .

You can click an to view more detailed information or scroll down to see overall operation metrics.

You can adjust the overview's timeframe and filter by client in the top right corner or reset the defaults.

Operations Overview in GraphOS Studio

Operation navigation

By default, the left sidebar shows a paginated list of all s, but you can use it to hone in on certain ones. Specifically, you can:

  • Search for a particular by its name
  • Filter s by their type (queries, s, s) or whether they are unregistered or unnamed
The Insights page in GraphOS Studio
  • Sort s (descending or ascending):
    • Alphabetically
    • By total requests (count)
    • By request rate in requests per minute (rpm)
    • By total error (count)
    • By error rate
    • By error percentage (%)
    • By cache hit percentage (%)
    • By p50 Cache TTL in seconds, minutes (s, min)
    • By p50, p90, p95, and p99 service time in milliseconds, seconds, or minutes (ms, s, min)
    • By total duration in milliseconds, seconds, minutes, or hours (ms, s, min, hr)
    • By signature size in bytes (B, KB)
The Insights page in GraphOS Studio

As with the s overview, you can click an to view more detailed information.

Operation metrics

Directly below the Operations Overview, you can find the following overall metric charts:

The s included in the request metric charts are queries, s, and s. Request charts don't include data on subscription notifications, which are shown separately in charts.


A specific operation's detail page shows metrics instead of general request metrics.

Request rate

The Insights page in GraphOS Studio

The request rate chart enables you to keep an eye on your 's traffic over time. Abrupt spikes or drops in request rates can highlight potential performance bottlenecks or shifts in user behavior.

Request rate metrics can also help with capacity planning. By tracking request rate trends, you can make informed decisions regarding infrastructure scaling. You can also rely on these graphs for anomaly detection, including identifying issues like DDoS attacks, application errors, or resource constraints.

Subscription notification rate

The Insights page in GraphOS Studio

The rate is the total number of updates ("notifications") sent to clients as the result of all subscriptions over a specified time. A sudden spike in rate could indicate a surge in real-time activity and help you anticipate the need for scaling your infrastructure.

Request latency

The Insights page in GraphOS Studio

Request latency measures the time it takes for a GraphQL to be processed and to return a response to the client. Slow operations can lead to sluggish applications and frustrated users.

Request latency metrics provide crucial insights into the performance of various components of your services, such as s, s, and third-party services. This data can help you identify areas where optimization is needed.

Subscription notification latency

The Insights page in GraphOS Studio

latency measures the time it takes for your graph to send updates to clients due to a change in your graph's data.

For example, imagine a chat app using s like this:

  • Step 0. A is defined in your graph's . It might look something like this:

    type Subscription {
    newMessage(chatId: ID!): Message

    This is called newMessage and takes a chatId as an . It is used to subscribe to new messages in a specific chat.

  • Step 1. A client application initiates a WebSocket connection to the graph. The WebSocket connection allows for real-time communication between the client and the graph.

  • Step 2. When a user joins a chat or opens a messaging window, the client sends a request to the graph. For example:

    subscription {
    newMessage(chatId: "123") {

    This tells the graph to send new messages for the chat with chatId "123" to the client in real-time. The client specifies which s of the Message type it wants to receive.

  • Step 3. When a user sends a new message within the specified chat, the client initiates a GraphQL to create the message. A mutation handles the request, including inserting data and returning a response.

  • Step 4. The graph publishes the new message data to the subscribed clients. It sends the new message data as a response to the client's over the WebSocket connection.

  • Step 5. The client application receives the new message data and updates the chat interface in real-time. The user sees the incoming message instantly without needing to refresh or manually request updates.

The latency is the time between steps 4 and 5, from when your graph sends the update—often via your router—to when the client receives it.

Low latency is crucial for real-time applications to deliver data promptly. High latency can indicate network issues. It can also indicate slow performance or inefficient data fetching for federated s.

Federated subscription notification latency

Federated subscriptions are s that rely on data from multiple s. Federated subscriptions have an additional step after step 3: the Apollo must fetch data from any other necessary subgraphs before publishing an aggregated response to clients.

Apollo Router

For federated s, latency is measured from when the receives a response from one 's until the client receives an aggregated response, including the time it takes the router to fetch data from subsequent subgraphs and aggregate it into a single response.

Since fetching data from subsequent s requires those subgraphs' s to complete, high latency in federated s can indicate slow resolver performance.

Request latency distribution

The Insights page in GraphOS Studio

The request latency distribution graph illustrates the frequency and volume of your request latencies. This graph can help you identify central tendencies, variability, and patterns in your request latency.

Subscription notification latency distribution

The Insights page in GraphOS Studio

The latency distribution graph offers the same data and insights as the request latency distribution histogram but includes only subscription notification latency rather than all requests' latency.

Deferred fields in operation metrics

You can use the @defer to defer returning data for certain s in your . Using @defer doesn't affect latency metrics since they only take into account the initial response containing non-deferred s. You can view deferred fields' execution times in resolver-level traces.

Operation details

When you click an , you open detailed information for that operation in the main insights view. You can use the toggles below the operation name to view the operation's usage, error metrics, or traces.

The Insights page in GraphOS Studio

The main Usage view includes Client Usage information and the 's operation signature and query plan as a chart or text, which you can view by clicking View Operation.

The Insights page in GraphOS Studio

Below the client usage information, you can see the same operation metrics as on the operations overview page, but including only data for the particular you're viewing.

Subscription metrics

If you view a specific 's detail page, you see charts containing only data about that subscription. These include all the subscription notification metrics shown in the s overview. A 's detail page shows metrics instead of the request metrics on the operations overview.

Resolver-level traces

If you enable trace reporting in your s, Studio can display -level trace information about each .

Traces tab for an operation in GraphOS Studio

The Traces tab for an provides a breakdown of timing and error information for each resolved as part of that operation. Traces help you identify opportunities to improve your 's overall performance by optimizing whichever s currently act as a bottleneck.

Deferred fetches

The execution time for deferred fetches only includes the time it takes for the deferred 's to complete, not the time the response to the client with those fields was deferred.

Enabling traces

If your s use Apollo Server with the @apollo/subgraph library, federated trace reporting is enabled by default. You can customize Apollo Server's trace reporting behavior with the inline trace plugin.

For instructions for third-party GraphQL servers, refer to the documentation for the specific server library your uses.


Not all subgraph-compatible libraries support federated trace reporting.

To confirm the support status for your library, check its FEDERATED TRACING entry in Federation-compatible subgraph implementations.

Datadog forwarding
Field usage
Edit on GitHubEditForumsDiscord