Monitor daily LLM cost burn rate using records-based custom alerts

• Latest Dynatrace
• Tutorial
• 3-min read
• Published May 28, 2026

Record-based custom alert monitors how many records match a specific condition within a defined timeframe. When any record goes outside your expected threshold, Anomaly Detection creates an alert. This approach allows you to:

Scenario

Suppose your organization allocates a monthly LLM budget of $10,000 and wants to monitor daily burn rate to implement proactive cost controls. To achieve this, you can divide the monthly budget into a daily baseline (for example, around $300/day) and set alert thresholds to detect a cost drift early. In this scenario, you want to:

Who is this for?

This guide is written for anyone who:

What will you learn?

In this tutorial, you'll learn how to:

Before you begin

Prerequisites

Prior knowledge

Set up a custom alert for LLM burn rate monitoring

2. Configure a records-based custom alert

4. In Data type, choose Records.

5. In Query, provide the DQL query to fetch and filter your data. Here's an example of a query that creates a total_cost alerting condition from 400 to 450 and detects any records from the whole day (from:@d) with total_cost value matching the condition.

   timeseries input = sum(gen_ai.client.token.usage), interval:1m, from:@d
   | join [
       timeseries output = sum(gen_ai.client.token.usage),interval:1m,
         filter: { `gen_ai.token.type` == "output" }
     ],
     on: { timeframe, interval },
     fields: { output }
   | fieldsAdd inputCost = input[] * 0.0000074,
             outputCost = output[] * 0.000023
   | fieldsAdd cost = inputCost[] + outputCost[]
   | fieldsAdd total_cost = arrayAvg(cost)
   | fields total_cost, timeframe, interval
   | fieldsAdd metricName = "Total amount of tokens used"
   | filter total_cost >= 400 and total_cost <= 450 // WARNING
   Run in Playground

   from:@d allows you to track data from the beginning of the day to its end. If you don't specify a from parameter, the default of 2 hours is used. To learn more, see Anomaly detection configuration.

6. In Alert identity fields, choose the metricName field.

   Choosing correct alert identity fields

   To ensure that your custom alert works as intended, you need to choose only the stable fields that create a unique alert instance.

   In this example, your query outputs four fields: total_cost, timeframe, interval, and metricName.

   • Choose metricName: this is a stable dimension with a constant string value that stays the same over time and across all alerts.

     • If you choose metricName as the alert identifier, Anomaly Detection creates one alert for a metricName with value Total amount of tokens used, regardless of changes in total_cost value. This ensures that any updates regarding the threshold violation are kept inside a single alert, providing clear insights into the event.

   • Don't choose total_cost: this is a typical volatile dimension, a numeric value field that changes over time. For example, total_cost can increase from 410 to 425 within an hour depending on the LLM token usage.

     • If you choose this field as the alert identifier, Anomaly Detection creates a new alert after each change in cost value, which can result in duplicate and false alerts.

   For more examples of choosing a proper alert identity field, see Anomaly detection configuration.

An example of configured records-based alert scope and query

Create a query for a records-based alert

3. Configure an event template using additional fields

You can use both volatile and stable fields to enrich your event description and get a better insight.

7. Set Title to WARNING: Daily LLM cost.

8. Set Event name to WARNING: Daily LLM cost.

9. Set Event description to the following:

   WARNING!
   The daily budget of {metricName} has reached the total cost {total_cost}.

10. Provide the Event properties:

    • Set dt.smartscape_source.id value to {dt.smartscape_source.id}.

    • Set event.type value to WARNING.

      The WARNING event type doesn't open a problem, but can be used in dashboards and sent as a Slack message. If you want Anomaly Detection to open a problem after a threshold violation:

      1. Change the last query line to: | filter total_cost >= 450 // CRITICAL.
      2. Set event.type value to CUSTOM_ALERT.

An example of a configured warning event template

An example of a warning event configuration for LLM burn rate monitoring with a records-based alert

Conclusion

You have created a custom alert that captures input and output token usage on a daily basis and tracks data from the whole day. If any matching records are found, you receive a WARNING alert, which allows you to implement proactive cost controls, such as result caching, cheaper model variants, or prompt optimization.

Going forward, you can adapt and edit the query to divide and monitor incoming data at different granularities—user, feature, model—so you can get insight into which of them drive spending.