Monitoring consumption calculation

Dynatrace monitoring consumption is based on various types of monitoring units that are consumed by your Dynatrace environment during the monitoring of your applications and related services. Details of these monitoring unit types and how these units are consumed are outlined below.

Unless otherwise stated, the monitoring-unit consumption details explained here apply to both SaaS and Managed deployments. To get started using Dynatrace, contact Dynatrace Sales. Your sales representative will provide you with further details.

This page is provided for informational purposes only. The terms of the Dynatrace free trial offer and/or your Dynatrace license will be applied to any use of Dynatrace products or services.

Host monitoring

A host unit is the size of a host for monitoring-consumption purposes (based on the amount of RAM provided by a host). For full-stack monitoring, a host with 16 GB of RAM (or any portion thereof) equates to 1 host unit. For cloud-infrastructure monitoring, a host with 16 GB of RAM (or any portion thereof) equates to 0.3 of a host unit.

Max. RAM Host units (Full-stack*) Host units (Cloud infrastructure-only)
1.6 GB 0.1 0.03
4 GB 0.25 0.075
8 GB 0.5 0.15
16 GB 1 0.3
32 GB 2 0.6
48 GB 3 0.9
64 GB 4 1.2
n x 16 GB n n x 0.3

* For full-stack monitoring, fractional host units are only available for hosts that have fewer than 16 GB RAM.

The total host unit count is the sum of the host units of all monitored hosts.

Host unit hours

A host unit hour represents the consumption of a host unit over a time period. 1 host unit hour equates to 1 host unit being consumed for 1 hour. A host with 16 GB of RAM (i.e., 1 host unit) running for a full day consumes 24 host unit hours.

Host unit hours calculation example

For example, say you have 1,000 host unit hours available and you want to monitor a host that has 64 GB RAM (which equates to 4 host units). If you keep the host running for a full day, it will consume 96 host unit hours.
4 (host units) x 24 (hours a day) = 96 (host unit hours)

The 1,000 host unit hours will be consumed in slightly more than 10 days.
4 (host units) x 24 (hours) x 10 (days) = 960 host unit hours

Free-trial host unit hours

Host unit hours are used for Dynatrace free trials. When you sign up for a Dynatrace free trial, you receive a certain number of host unit hours to evaluate Dynatrace.

Apply host unit hours to demand spikes and select projects

If you know in advance that your base quota of host units will be exceeded due to holiday demand or a short-lived project (for example, on Black Friday or during a one-time testing initiative), you can use host unit hours rather than host units to manage variable traffic spikes. For example, if you have a pool of 9,000 host unit hours and 100 host units, during Black Friday, you'll need more hosts to scale up for the increased traffic on your site. In such a case, you have the option of using all 9,000 host unit hours in a single day. This would enable you to connect an additional 375 host units (475 total maximum) to Dynatrace for one day.
9,000 (host unit hours) / 24 (hours) + 100 (base quota of host units) = 475 (max. host units)

Host unit hour overages

If you've arranged for an allotment of host units to monitor your hosts and you're entitled to exceed this number (i.e., overages are allowed for your account), the overages will be calculated in host unit hours. For example, if you've arranged to monitor up to 10 host units (a maximum of 160 GB total RAM) and your account allows for overages, if you connect another host that equates to 2 host units (16-32 GB RAM) you'll have 12 host units in total and will therefore have exceeded your quota by 2 host units. If you continue to monitor your hosts using 12 host units for a full week, you'll accrue an overage of 336 host unit hours.
2 (host units) x 24 (hours a day) x 7 (days) = 336 (overage host unit hours)

Digital Experience Monitoring

Digital Experience Monitoring (DEM) units are used to consume Dynatrace Real User Monitoring, Synthetic monitoring, and Session Replay. The table below explains the rate at which DEM units are consumed per each capability type and unit of measure.

Unit of measure Capability Consumption per unit of measure
Synthetic action Browser monitors, browser clickpaths 1.0 DEM
Synthetic request HTTP monitor 0.1 DEM
User session* Real User Monitoring (Session Replay disabled) 0.25 DEM
User session* Real User Monitoring (Session Replay enabled) 1.0 DEM

* Only the user sessions of real users are counted in your consumption of user sessions. The user sessions of synthetic users and "robots" aren't counted when calculating your monitoring consumption.

Real User Monitoring (RUM)

A single Real User Monitoring session (i.e., a "user session") is defined as a sequence of interactions between a user with a browser-based web application or a native iOS or Android mobile app within an interval and with at least two user actions. A user action is a button click or app start that triggers a web request (for example, a page load or a page-view navigation). Interactions that include only one user action are considered “bounced” and aren't counted. A user who interacts with more than one web application or app at the same time consumes one session for each web application or app, except when the interaction is considered “bounced”. A session ends when a) the browser running a web application is closed or has been inactive for more than 30 minutes, b) the mobile app is closed or the client is inactive for more than 30 minutes, or c) after 60 minutes of continuous interaction with the web application or app.

If you've set up an annual RUM sessions quota, your usage will reset annually.

Synthetic actions and requests

A browser monitor or browser clickpath “synthetic action” is an interaction with a synthetic browser that triggers a web request that includes a page load, navigation event, or action that triggers an XHR or Fetch request. Browser monitors perform a single synthetic interaction (for example, measuring the performance and availability of a single URL) and consume one synthetic action per execution. Clickpath monitors are sequences of pre-recorded synthetic actions. Clickpaths consume one action per each interaction that triggers a web request. Scroll downs, keystrokes, or clicks that don't trigger web requests aren't counted as actions.

An HTTP monitor consists of one or multiple HTTP(S) requests (for example, GET, POST, HEAD requests). Each request executed by an HTTP monitor equates to one synthetic request.

# Synthetic actions/requests consumed per monitor = (# Synthetic actions included in monitor) x (# Executions per hour) x (# Locations) x # Hours

XHR or Fetch requests that are made by a synthetic browser as the result of a user action like a page load, which isn't directly triggered by user input, don't result in user actions and therefore aren't counted. Such XHR and Fetch calls are considered child requests of synthetic actions.

Synthetic actions/requests calculation example

For example, a recorded browser clickpath that navigates through 2 pages and clicks 1 button that triggers an XHR or Fetch request consumes 3 synthetic actions. If such a synthetic monitor runs every 15 minutes from 2 locations for 1 day, the browser clickpath will consume 576 synthetic actions per day.
3 (synthetic actions) x 4 (monitor executions per hour) x 2 (locations) x 24 (hours per day) = 576 (synthetic actions)

For more details, see synthetic monitoring.

Digital Experience Monitoring overages

If you've arranged for Digital Experience Monitoring overages (i.e., your account allows you to exceed the maximum limit of DEM units), the units you consume as overage are counted just as with regular DEM unit consumption; each additional overage session or synthetic test increases the amount of DEM units consumed by your account.

Log Analytics

Dynatrace SaaS - Annual average log storage (GB)

Log Analytics consumption is based on anticipated GB of annual average log storage size, which is calculated as the average annual daily ingestion of uncompressed log data multiplied by the number of days. Once this limit is reached, you need to contact Dynatrace Sales to arrange for additional capacity.
Annual average daily log storage = Actual annual storage / (# of days)

Log storage calculation example

Say, for example, that your Log Analytics agreement is configured for 90 days and you've arranged for 450 GB of annual daily average storage. The anticipated average daily ingestion of log data in this case would be 5 GB.
450 (GB; base quota of annual average storage) / 90 (days) = 5 (GB; anticipated average daily ingestion)

Once the annual equivalent of 1,825 GB is ingested and exceeded, the annual average storage size of 450 GB is also reached.
5 (GB; anticipated average daily ingestion) x 365 (days) = 1,825 (GB; anticipated average annual ingestion)

Continuing with the example above, if after six months your actual log ingestion is only 912.5 GB (50% of the anticipated 1,825 GB), then you might decide to re-configure your Log Analytics allotment down to 45 days while leaving the annual average storage capacity unchanged at 450 GB. In this case, the anticipated average daily ingestion of log data for the subsequent six months would be 10 GB.
450 (GB; average annual capacity) / 45 (days) = 10 (GB; anticipated average daily ingestion)

Once the annual equivalent of 2,737.5 GB is ingested, the annual average storage size of 450 GB is also reached.
(5 x 182.5) + (10 x 182.5) = 2,737.5

If you've arranged for annual log storage capacity, your usage will reset annually.

Log Analytics overages - SaaS deployments

If you've arranged for Log Analytics overages so that you can exceed your agreed upon maximum limit of anticipated annual average storage size, your overages will be calculated based on the difference between your storage size limit and your actual storage size. For example, if you have an agreed upon storage limit of 450 GB and your actual consumption is 500 GB, you'll have 50 GB in overages.
500 (GB; actual average storage size) - 450 (GB; average storage size limit) = 50 (GB; overages)

Dynatrace Managed - Annual average log storage (GB)

Log Analytics consumption is based on anticipated GB of annual average log storage size, which is calculated as the average annual daily ingestion of uncompressed log data multiplied by the number of days. Once this limit is reached, you need to contact Dynatrace Sales to arrange for additional capacity.

For example, if during an annual period the total log data sent to your Dynatrace Managed Cluster is 730 GB, then the "per day" rate of annual average ingestion would be 2 GB.
730 (GB; actual annual ingestion) / 365 (days) = 2 (GB; annual average daily ingestion)

If you've arranged for annual log storage capacity, your usage will reset annually.

Log Analytics overages - Managed deployments

If you've arranged for Log Analytics overages so that you can exceed your agreed upon maximum limit of daily log storage, your overages will be calculated based on the difference between your daily storage limit and your actual daily storage size. For example, if you have an agreed upon storage limit of 10 GB/day and your actual consumption is 12 GB/day, you'll have 2 GB/day in overages.
12 (GB; actual daily log storage) - 10 (GB; daily log storage limit) = 2 (GB; daily overage)

Custom metrics

Custom metric ingestion and analysis isn't included in out-of-the-box Dynatrace technology support. To arrange for custom metric ingestion and analysis, contact Dynatrace Sales. For full details on setup and consumption of custom metrics within Dynatrace, see Custom metric ingestion and analysis.

Custom metrics are consumed per component and per collected dimensional value. Here are some examples:

  1. A File count metric actively collected for 2 hosts equates to 2 custom metrics.
  2. A File count metric actively collected for 5 different folders across 10 hosts equates to 50 custom metrics.
    5 * 10 = 50 (custom metrics)
  3. A File count metric actively collected for 5 different folders (with each folder representing a separate dimensional value) equates to 5 custom metrics.
    5 * 1 = 5 (custom metrics)

"Actively collected" means that at least one data point is reported for the custom metric within a sliding window of 28 days. Custom metrics aren't factored into your consumption when no data is written to them for 28 days or more.

Custom metrics overages

If your agreement specifies a maximum limit of 10K custom metrics ingested during any 28-day period, and there's risk that you'll exceed this amount during periods of peak traffic, consider setting up overages for custom metrics. With overages enabled, at peak times you can go beyond the maximum limit.

Say, for example, that you have an agreement for a limit of 10K custom metrics during any 28-day period, you have overages enabled for custom metrics, and for the first 15 days of Dynatrace usage your environment ingests 9K custom metrics that are reported by custom OneAgent plugins. If on day 16 your team enables a custom plugin that collects an additional 3K custom metrics (now 12K total custom metrics), you'll have 2K in custom metrics overages.
12K (actual custom metrics usage) - 10K (custom metrics limit) = 2K (custom metrics overages)

Free tier of custom metrics

Each Dynatrace environment (SaaS or Managed) comes with 100 free custom metrics. Additionally, 10 free custom metrics are provided for each of your allotted host units. For example, if you have 100 host units, you will be provided with 1,100 custom metrics.
100 + 10 * 100 = 1,100 (custom metrics)

There's a maximum free tier limit of 10,000 custom metrics.

If you have multiple Dynatrace SaaS environments under a single Dynatrace account, your free tier of custom metrics will be evenly distributed across your monitored environments.