Node Service

​

FAQ

​

How do I view my REST API requests, errors, and latency?

1. Filter by network, access key, method, and/or time range. Changing these filters re-fetches all the insights on the page.
2. Summary metrics for a quick look at your error rates. Of course, a low error rate over a long period could hide one day that had a high error-rate, so it’s worth occasionally looking at the graphs below. Looks like there’s a significant percentage of non-rate-limit errors for my test account, so I should look at the graphs below to see which errors I’m getting
3. If you hover over a section of a chart bar, you’ll see details about what it represents.
4. You can click items in the legend to hide or show them.
5. There are more graphs below! Scroll down to view error and latency insights.

​

What each graph shows

1. Request count by method: This shows the count of all requests, including all errors, broken down by method (assuming you’ve selected “All methods” in the filter at the top of the page).
2. Error count by Aptos error code: This shows the count of requests that got an Aptos error code, grouped by code. If you filter the page by an individual method, e.g. POST /transactions, you’ll only see the errors you received on that method. This graph and the next pair well with our Error Guide’s sections on the Aptos Rest API.
3. Error count by HTTP error code: This shows the count of requests that got an HTTP error code, grouped by code. If you filter the page by an individual method, e.g. POST /transactions, you’ll only see the errors you received on that method.
4. Error ratio by method: This shows the error ratio for each method. For example, if you sent 100 POST /transactions requests in a time bucket (e.g. a day) and you got an error on two of them, your error ratio would be 2% for that method in that time bucket. If you see a high error ratio it’s useful to scroll up to the “Request count by method” graph to see how many of that method you sent in a time bucket: a 100% error ratio could happen if you send one request and it gets an error.
5. Requests latency by method - P50: This shows the 50th percentile latency for each method across all of its requests, including errors. This is the latency within our system, so the latency you observe will be a little higher because of network travel time.
6. Requests latency by method - P95: This shows the 95th percentile latency for each method across all of its requests, including errors. This is the latency within our system, so the latency you observe will be a little higher because of network travel time.
7. Successful requests latency: This shows the 50th and 95th percentile latencies for all of your successful requests. It does not group by method. This is the latency within our system, so the latency you observe will be a little higher because of network travel time.
8. Requests with non-rate-limit errors latency: This shows the 50th and 95th percentile latencies for all of your requests that got an error (excluding rate-limit-errors since they have very low latency). It does not group by method. This is the latency within our system, so the latency you observe will be a little higher because of network travel time.

​

How do I view my GraphQL API requests, errors, and latency?

1. Filter by network, access key, method, and/or time range. Changing these filters re-fetches all the insights on the page.
2. Summary metrics for a quick look at your error rates. Of course, a low error rate over a long period could hide one day that had a high error-rate, so it’s worth occasionally looking at the graphs below.
3. If you hover over a section of a chart bar, you’ll see details about what it represents.
4. You can click items in the legend to hide or show them. This works when there are two or more legend entries.
5. There are more graphs below! Scroll down to view error and latency insights.

​

What each graph shows

1. HTTP requests by status code: All of your requests, grouped by HTTP response code.
2. GraphQL requests: The count of your GraphQL requests, grouped by whether or not there was at least one GraphQL error in the response. This number will not equal your HTTP request count if you sent any HTTP requests with multiple GraphQL requests or if you had certain non-HTTP 200 response codes where we didn’t try to process the request body, like a HTTP 429 rate limit.
3. GraphQL request error ratio: The percentage of your GraphQL requests that contained GraphQL errors. For more information on errors, see our Error Guide’s section on Aptos GraphQL API.
4. HTTP request latency: The 50th percentile and 95th percentile latency of your HTTP requests. This is the latency within our system, so the latency you observe will be a little higher because of network travel time.
5. Compute Units: The total compute units of the requests you sent in the time bucket. For more on compute unites, see below.

await aptosClient.queryIndexer({
  query: {
    query: `query MyQuery {
      ledger_infos {
        chain_id
      }
      processor_status {
        last_transaction_timestamp
      }
    }`
  }
});

1. Occurrences: how often we ran a given root-field query for you (including responses with GraphQL errors).
2. Error ratio: what percentage of the time did HTTP 200 requests containing this root field have GraphQL errors? For more information on errors, see our Error Guide’s section on Aptos GraphQL API.
3. HTTP request latency containing root field (P50): How long did the 50th percentile of HTTP 200 requests containing this root field take (including responses with GraphQL errors).
4. HTTP request latency containing root field (P95): How long did the 95th percentile of HTTP 200 requests containing this root field take (including responses with GraphQL errors).

1. If you have the toggle on to show HTTP requests when only one root field was present, you’re measuring the latency of this exact query (because that’s the only operation the HTTP request did). If you have the toggle off, you’re measuring the latency of HTTP requests that contain this query (but could contain others as well, in which case it’s not a direct measure of this specific query’s latency).
2. This is the latency within our system, so the latency you observe will be a little higher because of network travel time.

​

What are QPS and CUPS?

• see if you hit any QPS rate limits. Look for rate-limit error codes for (HTTP 429 )
• get an approximation of recent QPS by looking at your Node Service API Insights in the dashboard and selecting a specific access key - or all keys on a network - and the time range “Last 60 minutes”. Then, take your highest bar and divide it by 60 (since each bar represents 1 minute).

• see if you hit any QPS rate limits. Look for rate-limit error code HTTP 429.
• get an approximation of recent CUPS by selecting a specific access key - or all keys on a network - and the time range “Last 60 minutes”. Then, take your highest bar and divide it by 60 (since each bar represents 1 minute).

​

How do I monitor my request and CU count

​

REST API request count by day

​

GraphQL API CU count by day

​

How do I monitor my rate-limits and QPS / CUPS?

​

REST API rate-limits and QPS

​

GraphQL API rate-limits and CUPS