Manage DPS costs

The Dynatrace Platform Subscription (DPS) model has transformed how we deliver the total value of the Dynatrace platform to our customers, providing seamless access to any platform capability in any quantity.

Managing a Dynatrace Platform Subscription budget requires balancing the usage of Dynatrace features against an annual budget. With too little flexibility, the organization fails to benefit from capabilities that can transform its observability and security processes. With too much flexibility, the costs can exceed the budget.

While there is no penalty for exceeding your Dynatrace Platform Subscription budget (Dynatrace applies the same rate card for on-demand usage without additional fees or premium pricing), administrators still want the ability to manage their usage within the planned budget. Dynatrace provides several ways to manage your DPS costs:

  • The Account Management portal provides transparency into all Dynatrace costs and usage.
  • Cost monitors and Budgets provide automated and user-defined notifications of changes to forecast costs.
  • Detailed usage analysis is provided to assist you in triaging cost increases.
  • The Dynatrace API provides programmatic access to cost and usage information that you can leverage to support custom workflows.
  • Cost allocation helps you manage internal costs between departments, allowing you to hold business units accountable for their IT spending.

Combined, these capabilities enable you to manage your Dynatrace Platform Subscription costs with no need to set up limits that can threaten your business by stopping essential monitoring.

Account Management

Account Management provides several capabilities that offer complete transparency into costs and usage that help you understand and manage costs and prevent billing surprises.

The DPS Summary view provides vital information on your overall DPS consumption, including subscription information, actual consumption, and forecast consumption.

DPS Summary view

  • The chart and forecast portions of the budget summary show total consumption across all environments and capabilities.
  • The Environment table beneath the chart shows you the total and the last 30 days' costs by environment. You can drill down into capability usage for a specific environment by selecting View details.

budget summary

Cost and usage details provides insights for the most recent 30-day period:

  • The default chart displays total daily costs for the last 30 days (your current “run-rate”). If the chart indicates an overall increase, the current run rate indicates growth.
  • Select table row headers to sort the table by total or 30-day costs to determine the most significant contributors to subscription spending across your contract term.
  • Using the table, sort by budget-to-date cost (descending) to find the capability that has consumed the most cost over the term of the subscription; sorting by last 30-day finds the capability that is currently consuming the most costs.
  • To determine whether growth is specific to an environment, use the information from the environment table above to understand the top consumers by environment and filter on these to determine which environment shows increasing costs.
  • You can view raw usage information for any specific capability by selecting the Usage summary link. Because each capability has a different unit of measurement, you need to select a capability to chart its usage.

Once a capability is identified as a primary consumer of costs, select View Details to analyze which environment contributes the most costs for the specified capability. Environment cost and usage analysis shows a breakdown of capability costs for the chosen environment. The benefit of this drill-down sheet is that it shows combined cost and usage and supports custom timeframes.

breakdown of capability costs for each environment

More information on tracking DPS usage in Account Management is available in Track DPS usage documentation.

Smart forecast

Your Dynatrace Platform Subscription provides a budget summary that forecasts costs through the end of the subscription period. The algorithms use linear forecasting techniques to predict future usage from the past month of consumption data. The algorithm gives more weight to more recent data points to adapt to changing consumption behavior. The forecast also provides a range of values. Hover over the chart to display the median forecast value along with the predicted upper and lower ranges of the forecast. No forecast is shown until 15 days of consumption data is available to generate a forecast.

The Forecast events panel displays the projected costs (percentage and cost) forecast to incur at the end of the annual commitment period. When the forecast usage exceeds the annual commitment, the date when the forecast exceeds the annual commitment is shown.

Forecast events

Frequently asked questions

If there is a spike in usage, how quickly will the forecast recognize this?

A significant change in usage will only fully affect the forecast after a few days as the forecasting algorithm adapts to the new usage behavior. However, you may receive alerts that an unexpected cost change has been detected. See Cost Monitors below.

If the forecast changes significantly, how will I know?

License administrators will be notified by email whenever there is a significant change in week-over-week forecast, alerting them that something may require further analysis. See Cost Monitors below for details.

If the forecast exceeds the budgeted costs, how will I know?

License administrators are notified by email whenever the forecast is predicted to exceed the budget. See Cost Monitors below for further information.

Subscription History

Customers with a Dynatrace Platform Subscription can use the Subscription History feature to understand expired, active, and pending Dynatrace subscriptions and licenses. The Subscription History page allows you to open past licenses and subscriptions to understand historical usage and costs. To learn more about this feature, please refer DPS subscription history documentation.

Proactive notifications with cost monitors and budgets

The Dynatrace Platform Subscription model provides features that notify you about changes in your subscription costs:

  • Cost monitors analyze costs daily and notify you automatically when a significant forecast or spike in costs is detected.
  • Budgets allow you to define notification rules when account, environment, and capability costs exceed user-defined thresholds.

Cost monitors

Cost monitors help you manage your Dynatrace Platform Subscription budget and identify unexpected cost increases. They monitor your overall forecasted usage and warn you when costs increase significantly, or forecasts exceed user-defined threshold amounts. They also monitor daily costs at the capability and environment levels, alerting you when costs exceed predicted levels.

  • Cost monitors notify you when forecast costs at the end of the subscription exceed budget or when there are significant increases in the week-over-week forecast.
  • Cost monitors inspect costs for each capability in each environment daily and notify you when a capability exhibits an unexpected increase (above its upper forecast range), allowing you to stay on top of daily and weekly usage.

Cost monitors are enabled automatically for all DPS accounts and will notify license administrators by default without configuration. License administrators can adjust thresholds and configure email distribution at any time. This approach helps minimize surprise costs by ensuring that forecast and cost increases are automatically emailed to those users on the account identified as license administrators.

To learn more about cost monitors, please refer to cost monitor documentation.

Cost monitor scenario #1

I received a forecast notification informing me that “Forecast costs increased 15% week-over-week. Forecast costs at 75%.”

  • This notification indicates a significant weekly change in the forecast but also shows that the total forecast prediction is only at 75% of the overall commitment. As the forecast remains below the commitment, no action is required, but you may wish to analyze the increase's root cause to ensure it aligns with your adoption goals.
  • If you're still in the deployment phase of Dynatrace, you can ignore this kind of error, as increased weekly usage is expected.
  • If there was a significant increase in capability, you might also receive a Cost event notification– check the Cost Event table or Notification Center to identify capability spikes in a specific environment.

Cost monitor scenario #2

I received a forecast notification informing me that “Forecast costs [105%] exceed the defined threshold of 100%.”

  • This notification indicates that your current usage pattern will result in a possible overrun of 5% over budget.
  • If you're still in the deployment phase of Dynatrace, your current usage pattern may suggest ever-increasing usage, as the forecast algorithms can't anticipate deployment plans. Once deployment is complete, usage and costs will level off, and the forecast will also trend downwards after a few days as it detects a new usage pattern. If the forecast continues to show a budget overage 30 days after ramp-up finishes, your usage might be over budget.
  • To understand if your subscription usage is ramping up, select the View details link for the primary environment and increase the timeframe to the last 90 days or since the start of the subscription. This displays the cumulative cost of your subscription over time, allowing you to identify if costs are increasing or leveling off. Your forecast might show an exponential growth curve if the costs are not leveling off.
  • Once your annual commitment is reached, you can continue to use Dynatrace while incurring on-demand usage. Dynatrace applies the same rate card for on-demand usage without additional fees or premium pricing. You receive monthly invoices for on-demand costs until the next annual commitment period begins.

possible overrun scenario

Cost monitor scenario #3

I received a notification informing me, "Increase in Events – Query cost detected in environment [environment name].”

  • A cost event notification implies that a specific capability unexpectedly increased. Sometimes, this is attributable to an increase in a particular environment (as in this example); sometimes, it can be at the account level, suggesting that the capability increased in all environments.
  • Select the View details link for the cost event in the Capability cost and usage summary panel to open the capability cost and usage analysis filtered to the specific event.

cost events

This example shows a clear capability outlier on the selected day. Adjusting the time frame will give you a better sense of whether this is a one-off (suggesting that someone in your organization is experimenting with Dynatrace capabilities) or this is a non-forecast increase (indicating that the rise will persist, resulting in higher costs over time).

cost management

In such scenarios, if a specific capability is determined to be the reason for the notification, please refer to the following section, Detailed usage analysis for triage of cost increases, to identify the root cause of the increase.

Forecast and cost events are only estimates and therefore can be misleading in some cases. Forecasts are based on statistical models and therefore be relied on with caution.

Budgets

The Budgets feature tracks and notifies you when Dynatrace Platform Subscription costs hit a user-defined threshold. You can use Budgets at the account, environment, and capability level and configure notifications to email you when budgets are exceeded. Examples of supported use cases include:

  • Get notified when your subscription reaches 75%, 90%, and 100% of its annual commitment.
  • Set a budget threshold of 10% of total subscription costs for a lower “sandbox” environment.
  • Set a fixed threshold for a new capability and be notified when it reaches USD 1,000 in costs.

Budgets complement the existing Cost Monitor feature by allowing you to define custom thresholds at the environment and capability level. Learn more in Budgets documentation.

Detailed usage analysis for triage of cost increases

If an increase in consumption is identified, administrators want to identify the key contributors of increased costs to take appropriate remediation steps. Account Management supports this in two ways:

  • The Account Management web UI helps you identify which environment is the primary contributor to costs (using the environment summary table and the capability cost and usage analysis sheet) and which capability is the primary contributor (using the cost and usage details summary and environment cost and usage analysis sheet). These capabilities are covered in the previous section, Proactive notifications with cost monitors and budgets.
  • The platform provides usage details in the form of dedicated DPS Consumption metrics that can be viewed with the Data Explorer.

For Grail-powered capabilities in Dynatrace SaaS deployments, you additionally get access to pre-configured DQL statements that can be used in Notebooks to examine Grail-based usage.

Classic Dynatrace consumption capabilities, which previously supported consumption of Davis Data Unit (DDU) SKUs for Custom Events Classic, Custom Metrics Classic, Custom Traces Classic, Serverless Functions Classic, and Log Monitoring Classic, can be analyzed directly in the Account Management web UI and further with context-aware links to the Data Explorer.

Other capabilities support context-aware links to the Data Explorer, providing you with comprehensive reporting capabilities to analyze your Dynatrace platform usage.

The following capabilities provide context-aware links to Notebooks, allowing you to analyze usage in more detail:

  • Log Management and Analytics – Retain
  • Log Management and Analytics – Query
  • Events - Ingest & Process
  • Events – Retain
  • Events – Query
  • Metrics - Ingest & Process
  • Traces – Query
  • Automation Workflows
  • AppEngine Functions – Small

To illustrate how these capabilities work together, the following example shows increased usage in the Custom Metrics Classic capability, which causes the Dynatrace Platform Subscription forecast to increase unexpectedly:

  • The subscription in this example starts on March 01, 2023, and has a USD 2 million commitment over a year.
  • On May 25, 2023, Cost Monitors detected a variance in the forecast, showing a week-over-week increase of 14%, increasing the forecast to 110% of the commitment amount. The forecast predicts that the commitment level will exceed USD 2 million on January 20, 2024.

week-over-week increase of 14%

  • DPS cost monitors are automatically set up to notify license administrators if the forecast exceeds 100% or when a week-over-week variance greater than 10% is detected. An email with the following information is generated and sent to all license administrators who, upon selecting the link, are directed to the Account Management web UI for further analysis.

notify license administrators if the forecast exceeds 100%

  • Cost Monitors also detected an increase in Custom Metrics Classic in the Production environment, providing the starting point to determine what caused the increase.

increase in Custom Metrics Classic

  • The user selects the View Details link of the Cost event to start their analysis. This opens an analysis sheet filtered down to their environment and the Custom Metric Classic capability, identifying an apparent increase on the date identified in the cost events.

apparent increase in the Custom Metric Classic capability

  • The license administrator needs to determine whether a new metric was added or if there is an increase in an existing metric.

  • Account Management provides built-in analysis capabilities for Custom Events Classic, Custom Metrics Classic, Custom Traces Classic, Serverless Functions Classic, and Log Monitoring Classic. You can scroll down to see a list of metrics that contribute to the overall usage of this capability.

  • The table displays each metric, its current usage (based on the timeframe selected in the above chart), the use for the prior period, and the change in usage from the past to the current period.

  • Selecting the row headers allows you to find the metric that is either consuming the most or has changed the most. In the case below, there is a significant increase in two AWS metrics.

metric that is either consuming the most or has changed the most

  • You can chart any usage metric over the same period to understand when it increased and by how much. The action menu offers one-click contextual navigation to the Data Explorer in the Dynatrace platform if additional analysis is needed.

one-click contextual navigation

  • Account Management provides contextual navigation to analyze usage in the Data Explorer.

For Grail-powered capabilities in Dynatrace SaaS deployments, contextual navigation to a notebook containing the correct DQL queries for detailed analysis is provided.

contextual navigation to a Notebook

  • The Open details with Data Explorer link opens the related metric, allowing you to perform additional analysis within the Dynatrace platform.

additional analysis

Identify and resolve DPS consumption issues

This section summarizes how to identify the root causes of increased usage per DPS capability and how to resolve issues with unwanted or excessive consumption. Most DPS capabilities offer a set of DPS consumption metrics that can be analyzed in the Data Explorer to help identify increases in related costs.

Grail-based capabilities offer predefined DQL queries to be opened in Notebooks.

Full-Stack Monitoring

Potential root cause

  • The number of hosts monitored with Full-Stack Monitoring might have increased.
  • The memory footprint of hosts monitored with Full-Stack Monitoring might have increased.

How to verify

Use Data Explorer to chart (DPS) Full-Stack Monitoring billing usage per host and split by hosts to determine if there was an increase in the number of hosts monitored with Full-Stack Monitoring or if the memory footprint of the monitored hosts increased, and if so, to see which hosts are affected.

Resolution options

Disable host monitoring on unintentionally monitored Full-Stack hosts or switch to Infrastructure Monitoring for non-critical hosts.

Infrastructure Monitoring

Potential root cause

The number of hosts monitored with Infrastructure Monitoring increased.

How to verify

Use Data Explorer to chart (DPS) Infrastructure Monitoring billing usage to determine if there was an increase in the number of hosts monitored with Infrastructure Monitoring.

Resolution options

Disable host monitoring on unintentionally monitored hosts or switch to Foundation & Discovery for non-critical hosts.

Runtime Vulnerability Analytics (RVA)

Potential root cause

  • Application Security monitoring was enabled with Third-party or Code-Level Vulnerability Analytics.
  • Application Security monitoring rules changed, which led to an increased number of monitored hosts.
  • New hosts matching existing Application Security monitoring criteria were detected and are now monitored.
  • Monitored hosts running for longer periods of time.
  • Monitored hosts were assigned more memory.

How to verify

  • Check the Application Security settings and monitoring rules.
  • Use the Security Overview app to see the current host coverage stats.
  • Use Account Management for an environment view on usage and Data Explorer for deep insights into which hosts are responsible for the increase (for example, (DPS) Runtime Vulnerability Analytics billing usage per host, split by host).

Resolution options

  • Adjust Application Security monitoring rules to include only business-critical services and applications in your environment.
  • Disable monitoring for unused or non-critical technologies (for example, .NET, and Go).
  • Disable Code-level Vulnerability Analytics if there is no need for custom code monitoring.
  • Disable Third-party Vulnerability Analytics to permanently turn off Application Security monitoring.

Runtime Application Protection (RAP)

Potential root cause

  • Application Security monitoring was enabled with Runtime Application Protection.
  • Application Security monitoring rules changed, which led to increased number of monitored hosts.
  • New hosts matching existing Application Security monitoring criteria were detected and are now monitored.
  • Monitored hosts running for longer periods of time.
  • Monitored hosts were assigned more memory.

How to verify

  • Check the Application Security settings and monitoring rules.
  • Use Account Management for an environment view on usage and Data Explorer for deep insights on which hosts are responsible for the increase (for example, (DPS) Runtime Vulnerability Analytics billing usage per host, split by host).

Resolution options

  • Adjust Application Security monitoring rules to only include business-critical services and applications in your environment.
  • Disable monitoring for unused or non-critical technologies (for example, .NET, and Go).
  • Disable Runtime Application Protection to permanently turn off Application Security protection.

Real User Monitoring (RUM)

Potential root cause

Increased number of Sessions because of:

  • Enabling of RUM on more frontend applications
  • Increasing capture rate to 100% (if it was lower before)
  • Increased traffic on customer frontends

How to verify

In Data Explorer, chart the (DPS) Real-user monitoring (web and/or mobile) billing usage by frontend application metric to see

  • The number of frontend applications with enabled RUM
  • The Capture Rate per frontend application

Resolution options

  • Reduce capture rate.
  • Disable RUM on a selected frontend application.

RUM with Session Replay

Potential root cause

Increased number of sessions with Session Replay, because:

  • Turned on Session Replay on more applications
  • Increased capture rate to 100%
  • Increased traffic on customer applications

How to verify

In Data Explorer, chart the (DPS) Real-user monitoring (web) with Session Replay billing usage by application metric to see

  • The number of applications with Session Replay turned on
  • The Capture Rate per application

Resolution options

  • Disable Session Replay on applications.
  • Reduce capture rate.

Browser monitor / clickpath

Potential root cause

Increased number of executions because:

  • New monitors were added, or frequency increased, or customer starting executing it from higher number of locations
  • Clickpath definition change, adding more steps triggering web request or XHR

How to verify

  • Validate with team which synthetic monitor configuration changes were performed recently.
  • Check the configuration.

Resolution options

To limit consumption, consider limiting the number of executions by reducing the number of monitors, frequency, number of locations used, or the number of steps. Alternatively, disable some monitors.

Third-party Synthetic API

Potential root cause

More test results ingested to Dynatrace with Synthetic Third-party API.

How to verify

  • Check if there are new Third-party test results.
  • Check if for earlier existing Third-party test where there was an increase in the frequency or number of locations.

Resolution options

Consider how consumption can be limited by decreasing the amount of data ingested with Synthetic Third-Party API.

HTTP monitor

Potential root cause

Increased number of executions because:

  • New monitors were added, the frequency increased, or the customer started to execute the monitor from a higher number of locations
  • Multistep HTTP monitor configuration change, more steps have been added

How to verify

  • Validate with team which synthetic monitor configuration changes were performed recently.
  • Check the configuration.

Resolution options

Consider how you can limit the number of executions by reducing the number of monitors, frequency, number of locations used, or the number of steps. Alternatively, disable some monitors.

Logs - Ingest

Potential root cause

  • Problem: Unexpected increase in logs ingest.
  • Root cause: Someone enabled ingest of all logs in logs ingest rules.

How to verify

In Data Explorer, chart the (DPS) Total Log Monitoring Classic billing usage metric to see if there was an increase in total number of log records.

Resolution options

  • Use OneAgent filtering features to ingest relevant logs.
  • Add granular access control for logs configuration.

Logs - Retain

Potential root cause

  • Ingest increased significantly.
  • Retention time of buckets was changed.

Logs - Query

Potential root cause

  • Dashboards containing DQL queries to raw data set to auto-refresh.
  • High execution rates in Automations.
  • Query timeframes extended (in combination with Dashboards or Automations).

How to verify

Check the result of the following DQL query:

fetch dt.system.query_executions
| summarize sum = sum(scanned_bytes), by:{client.application_context}

Resolution options

Check refresh settings in Dashboards and execution settings in Automations.

Events - Ingest

Potential root cause

  • Someone created a new Business Event capture rule for the OneAgent.
  • Someone sent more data to the API endpoint.

Events - Retain

Potential root cause

Retention time of buckets was changed.

Events - Query

Potential root cause

One of the Business Analytics apps was installed and is now in use.

How to verify

Check the result of the following DQL query:

fetch dt.system.query_executions
| summarize sum = sum(scanned_bytes), by:{client.application_context}

Automation Workflow

Potential root cause

  • Sudden increase in workflow hours.
  • Rise in number of workflows.

As workflows are charged per existence duration (per workflow hours), the cost curve rises linearly over time.

How to verify

Resolution options

  • Discuss the value (added value, cost savings) of existing workflows.

  • Check for the possibility of merging several workflows (for example, alert notifications) into one.

    Alert notifications can be realized at no extra cost. See Notifications and alerting - Dynatrace Docs.

  • If necessary, remove the workflows that add less value.

AppEngine Functions - Small

Potential root cause

High execution rates in Automations.

How to verify

Check the result of the following DQL query:

fetch dt.system.events, scanLimitGBytes:-1
| filter event.kind == "BILLING_USAGE_EVENT"
| filter contains(event.type, "AppEngine Functions")
| summarize count(), by:{event.type}

Custom Metrics Classic

Potential root cause

  • Problem: Unexpected increase in custom metrics.
  • Root cause: a certain custom metric generates high consumption of metric data points.

How to verify

Use Data Explorer to

  • Chart (DPS) Recorded metric data points per metric key if there was an increase in metric data points consumption.
  • Discover which custom metric started reporting an increased number of metric data points.

Resolution options

  • If a custom metric comes from a cloud service, go to Settings and add/delete the custom metric from the cloud service.
  • If a custom metric comes from an extension, go to monitoring configurations of the extension and disable the feature set for the custom metric.

Log Monitoring Classic

Potential root cause

  • Problem: Unexpected increase in logs ingest.
  • Root cause: Someone enabled ingest of all logs in logs ingest rules.

How to verify

In Data Explorer, chart the (DPS) Total Log Monitoring Classic billing usage metric to see if there was an increase in total number of log records.

Resolution options

  • Use OneAgent filtering features to ingest relevant logs.
  • Add granular access control for logs configuration.

Custom Traces Classic

Potential root cause

  • Increased load for existing entities (for example, Black Friday scenarios).
  • Increased number of monitored entities.

How to verify

  • Determine entities emitting traces by charting the builtin:billing.custom_traces_classic.usage_by_entity:splitBy("dt.entity.monitored_entity"):auto:splitBy():count metric in Data Explorer.

  • Identify trace volume by entity charting the builtin:billing.custom_traces_classic.usage_by_entity:splitBy("dt.entity.monitored_entity") metric in Data Explorer.

Resolution options

Evaluate for which entities tracing is needed and consider reducing the number of monitored entities.

Custom Events Classic

Potential root cause

Someone is sending more data to the API endpoint.

Serverless Functions Classic

Potential root cause

  • Increased load for existing serverless functions (for example, Black Friday scenarios).
  • Increased number of monitored serverless functions.

How to verify

  • Look into the average number of invocations by function using the average of the builtin:billing.serverless_functions_classic.usage_by_function metric in Data Explorer.

  • Look whether total number of monitored functions has increased by using the count for the builtin:billing.serverless_functions_classic.usage_by_function metric in Data Explorer.

Resolution options

Evaluate for which serverless functions tracing is needed and consider using metrics only where appropriate. Alternatively, reduce the number of monitored functions.

Additional consideration for Workflows

A workflow can cause cost increases for any licensing capability depending on what the workflow does and how it is configured. For example, a cost increase in Query and AppEngine Functions may be caused by a workflow that starts every minute. This might be a misconfiguration or intentional. Either way, it requires consideration of Workflows in addition to the individual capability (Query or AppEngine Function in this example).

Analyze Grail-powered capabilities with Notebooks

Dynatrace SaaS customers (running on AWS or Azure) with a Dynatrace Platform Subscription have access to capabilities powered by Dynatrace Grail (for example, Log Management and Analytics), which provides drill-down capability from Account Management into notebooks, giving you deep insights into capability usage.

Each notebook drill-down includes sections with predefined queries. Notebooks can be saved and bookmarked for easy access. Depending on the respective DPS capability, sections might consist of:

Overview – Daily query usage per data type: Displays a daily view of query usage across all Grail data types ( Events powered by Grail) measured in GiBs queried. This corresponds with the usage and rated costs shown in Account Management. Users and Apps – query usage: This report allows you to determine which queries consume the most data and cost. Queries – usage per user or app: This allows you to determine which users or apps consume the most data.

In section Cost Monitors, Scenario 3, we identified an increase in Events – Query. Select the Actions menu (…) to display the Open details with Notebooks link.

open details with Notebooks

This action creates a new notebook with a customizable query that you can inspect and modify based on your organizational needs.

Select Rerun sections to execute the queries. (You'll receive a 403 error if you don't have the correct permissions, in which case you should consult your system administrator.)

These reports allow you to determine which queries or users need to be optimized to control costs for your organization. A costly query might need to be restricted by timeframe or run infrequently; a user might run many queries and be unaware of their associated costs, and some education on query cost controls might be required. If a single app is identified as the consumer of the most data, you might need to work with the developer to see if the app’s query usage can be optimized.

API access to all cost and usage information

A Dynatrace Platform Subscription provides comprehensive API access to cost and usage data at the account, environment, and capability levels. Forecast information and cost events are also accessible programmatically through the API.

For complete details, please refer to Dynatrace API documentation.

Note that the Account Management API uses an OAuth token separate from the platform access token. For more information on setting up authentication, please refer to OAuth clients.

The API allows you to leverage current usage, cost, and forecast information in third-party applications, and to take action based on changes in subscription costs. For example, if you want to manage the cost of Full Stack Monitoring in your sandbox environment and know that the daily cost should not exceed USD 10, one call to the API with the Full Stack Monitoring and environment key will provide the recent cost data, allowing you to take appropriate action.

You can also directly analyze and alert on billing usage metrics within a Dynatrace environment. Billing metrics are now available for DPS capabilities This allows you to create metric events and custom alerts based on any DPS capability usage metric.

usage query notebook

analyze and alert on billing usage metrics

Metric events are also exposed via APIs, allowing you to centrally manage usage across your environments.

Metric events exposed via API

References

Use APIs to support custom workflows

In addition to the notification capabilities provided with Cost Monitors and Budgets, you might want to take action when a cost or forecast threshold is reached.

Examples

  • Reduce Full Stack Monitoring for specific internal application hosts during non-office hours.
  • Reduce the amount of sessions covered by Session Replay; you might reduce the number of lower-value application sessions to a capture rate of 75%.

To achieve this, the following steps should be considered:

  • Create an oAuth token for the Enterprise API to access DPS cost, usage, and event information programmatically and a platform token to access the platform's configuration aspects. Refer to the following documentation on this:
  • Create a new workflow using a Schedule-based trigger that executes once daily. (Because costs are calculated daily, more frequent workflow execution is not warranted.) Note that you’ll be charged for consumption of Workflow and AppEngine hours.
  • The action might be one or more series of JavaScript statements that will:
    • Using the Account Management API:
      • Get a list of all active subscriptions.
      • View the current active Dynatrace Platform Subscription to get start, end, budget total, and total budget used detail.
      • For the current subscription, use the Usage or Cost endpoints to get cost/usage for any capability in any environment.
    • Using the information from the subscription and cost/usage endpoints, determine whether an action is required. This could include:
      • To adjust the RUM capture rate, use the PUT default application endpoint to reduce the value of the costControlUserSessionsPercentage element.
      • To disable Full Stack Monitoring on a specific host or host group during the weekend, consider updating the HostGroupAutoUpdateConfig object under the respective OneAgent configuration endpoint to turn full stack monitoring on/off during weekend days.
custom notifications

The workflow above can be extended to send custom notifications to Email and Slack addresses.

Manage cost allocation

If you need to understand how Dynatrace costs are distributed throughout your company structure (in other words, by department) based on usage and associated costs, use Cost allocation. All usage and correlated costs must be assigned to a company entity (for example, a department). The sum of all costs must equal the total cost for the company.

Dynatrace plans to release platform capabilities for cost-allocation support in Dynatrace SaaS in the near future. Customers wishing to explore a custom cost-allocation model before this release should reach out to their Dynatrace Customer Success Manager to learn more.

While no Dynatrace cost allocation feature is currently provided out-of-the-box, it's possible to set up partial cost allocation support for host monitoring, Application Security, and digital experience monitoring capabilities using a mix of custom dashboards, DPS billing metrics, and APIs. If you wish to explore such a custom cost allocation model before Dynatrace cost allocation is released, please reach out to your Dynatrace Customer Success Manager.

If you exceed your annual commitment

It's not possible to set hard upper limits on your environment's consumption of DPS capabilities because this might result in blind spots in mission-critical applications.

You can execute specific automation to reduce or disable monitoring via the DPS APIs to get costs for account, environment, capability, and forecast and execute automated remediation via platform configuration APIs. For instance, if you detect a cost event on a specific environment with Synthetic Monitoring, you can use the APIs to set or extend the maintenance windows in that environment.

There is no penalty if you exceed your annual commitment, and you can continue to use Dynatrace while incurring on-demand usage (Dynatrace applies the same rate card for on-demand usage without additional fees or premium pricing, and you will receive monthly invoices for on-demand costs until the next annual commitment period begins).

Related topics