Monitor key requests

Key requests are requests that need special attention, either because they're a critical measure of the success of your business (for example, a login request or a shopping-cart checkout request) or because they provide vital technical functionality that your application relies on.

Key requests feature dedicated metrics that you can manage via the web UI or API. You can create dedicated dashboard tiles for charting key requests, with direct access from your dashboard, and analyze key request long-term metric history in request charts.
Alerting is always enabled for key requests, even when they contribute less than 1% of throughput. They also provide custom thresholds.
Data retention periods of key requests are maintained as follows:

Data type
Retention period
Detailed code-level data
10 days
Aggregated code-level data
35 days
Long-term metric history
5 years

Key requests are highlighted in Key requests/endpoints of each service overview page. This visibility is particularly valuable for low-volume, high-importance requests that would otherwise appear at the bottom of Top requests.

The number of key requests is limited:

500 key requests per environment across all services.
100 key requests per service.

When you reach that limit, consider using calculated service metrics, which offer you a more flexible approach.

Create a key request (via web UI)

To mark a specific request as a key request

Go to Services or Services Classic (latest Dynatrace).
Select the relevant service from the list.
On the service overview page, select a View button (such as View requests, View dynamic requests, or View resource requests).
Scroll down to Top requests and select a request you want to mark as a key request.
On the request overview page, select More (…) > Mark as key request or Pin to dashboard.

After you manually identify a key request, its trend lines are retained perpetually.

Show key requests on a dashboard

To create a dashboard tile for a specific request

Go to Services or Services Classic (latest Dynatrace).
Select the relevant service from the list.
On the service overview page, select View (View requests, View dynamic requests, or View resource requests).
Scroll down to Key requests/endpoints and select a request you want to show on a dashboard.
On the request overview page, select More (…) > Pin to dashboard.
A new request-specific tile that shows the most important metrics for that particular request is then added to your dashboard.

Dashboard tiles include only data collected after the request has been marked as key request.

Rename key requests

Key request detection is name-based. When you apply a request naming rule, it can affect key requests. If you want Dynatrace to continue detecting renamed requests as key requests, you need to add the new name to the list of key request names.

Go to Services or Services Classic (latest Dynatrace) and select the service you want to configure.
Select More (…) > Settings.
On the Service settings page, go to the Key requests tab and select Add item to add the name to which the request naming rules apply.

Anomaly detection with key requests

Dynatrace assumes that low-volume requests are of less importance than high-volume and key requests. This means that requests that contribute less than 1% to the overall load of a service won't raise alerts unless their impact is significant enough that the service's overall response time or failure rate is affected. Because this default treatment is not appropriate for all low-volume requests, you should manually tag any important low-volume requests as key requests to ensure that they have standard alerting thresholds.

Request-specific alerting thresholds

Because certain requests may have specific response-time and failure-rate patterns, while others may have strict SLA thresholds, Dynatrace enables you to define custom alerting thresholds when anomalies are detected related to the performance of key requests. If set, key-request-level thresholds override service-level thresholds. To learn how to set request-level thresholds, see Thresholds for a specific web request.

Calculated service metric

As an alternative way to focus on particular requests, you can create a calculated service metric, based on the requests you need. This approach provides you more flexibility with alerting—you can use the calculated metric just like any built-in metric provided by Dynatrace.

Manage key requests via Settings API

You can manage key request configurations via the Settings API.

To be able to use the API you need an access token with Read settings (settings.read) and Write settings (settings.write) scopes. To learn how to obtain it, see Create an access token.

Create key request configuration

Follow the steps below to create a new key request configuration. Note that this procedure overwrites any existing configuration. If you want to modify an existing configuration, see the Update key request configuration section below.

To learn the format of the settings object, query its schema via the GET a schema call. The ID of key request schema is builtin:settings.subscriptions.service.
Create the JSON object for your settings.
Note that the scope of a key request is always a service. You must specify the service by its Dynatrace entity ID. To find out the entity ID of your service, use the GET entities list request.
```
[
  {
    "schemaId": "builtin:settings.subscriptions.service",
    "scope": "SERVICE-123456789",
    "value": {
      "keyRequestNames": [
        "/cart/checkout"
        ]
      }
  }
]
```
Use the POST an object endpoint to send your configuration.

Update key request configuration

To learn the format of the settings object, query its schema via the GET a schema call. The ID of key request schema is builtin:settings.subscriptions.service.
Note that the scope of a key request is always a service. You must specify the service by its Dynatrace entity ID. To find out the entity ID of your service, use the GET entities list request.
Query the current configuration via the GET objects call.
Create the JSON for your update.
1. Use the updateToken value from the previous step.
2. Modify the list of requests in the keyRequestNames array as needed.
  {
  "updateToken": "vu9U3hXY3q0ATAAkMG",
  "value": {
  "keyRequestNames": [
  "/cart/checkout",
  "/cart"
  ]
  }
  }
Use the PUT an object endpoint to send your configuration.