Try it free

Understand and manage Standard Function Calls consumption (DPS)

  • Latest Dynatrace
  • Explanation
  • 12-min read

Standard Function Calls is a DPS capability for running the backend of your app, written in TypeScript and executed within the Dynatrace JavaScript runtime. Consumption is measured in invocations.

This page explains how Standard Function Calls consumption is calculated, what's included, and how to track and manage your usage.

Invoking a Standard Function Call can trigger the ingest (and therefore implicitly the retention) of additional data or the execution of a DQL query.

How consumption is calculated

The unit of measure for Standard Function Calls consumption is an invocation, using the Standard Function Calls rate card item.

Dynatrace defines one invocation as each minute (or part thereof) of execution time for a single function call. One function call will consume either one or two invocations:

  • 0–60 seconds: one invocation.
  • 61–120 seconds: two invocations.
  • After 120 seconds, the function call will time out.

The total consumption is calculated by multiplying the number of invocations by your rate card price per invocation.

Billable consumption of Standard Function Calls occurs when:

  • App functions are invoked in a custom app.
  • Ad-hoc functions are invoked in Notebooks Notebooks, Dashboards Dashboards, Workflows Workflows, or directly via API.
  • Custom actions are invoked in workflows.
  • Non-LLM-based tools are invoked by Dynatrace's agentic AI. These are recorded under their own billing event type, AI Function Standard Call, using the same rate-card item and unit of measure as any other Standard Function Call.

For an overview of how Standard Function Calls, AI Units, and query consumption work together, see Agentic AppEngine overview (DPS).

Key terms

Function call

A single execution of a Standard Function Call, whether invoked directly, in a custom app, as part of a workflow, or by agentic AI.

Invocation

The billable unit of measure for Standard Function Calls. One function call consumes one invocation per minute (or part thereof) of execution time, up to two invocations.

Estimate your usage

The following examples show how agentic AI can generate AI Function Standard Calls without any AI Units being consumed.

External agent runs a predefined query (MCP)

If your own agent calls a tool through the MCP server to run a predefined query, for example fetch logs | filter loglevel == "ERROR":

  1. Your own agent calls a tool through the MCP server.
  2. The query is executed (execute-dql). This is billed as a Standard Function Call and query consumption.

No AI invocation is involved, so no AI Units are consumed.

External agent runs a forecast (MCP)

If your own agent calls a tool through the MCP server to run a forecast, for example to answer "Is CPU usage predicted to exceed 80%?":

  1. Your own agent calls a tool through the MCP server.
  2. Dynatrace calls the forecasting tool (timeseries-forecast). This is billed as a Standard Function Call.

No AI invocation is involved, so no AI Units are consumed.

Understand and manage your consumption

Dynatrace provides several ways to monitor and analyze your Standard Function Calls consumption.

  • Use Account Management for subscription-level totals, forecasts, costs, and breakdowns.
  • Use billing usage events for detailed DQL analysis, including AI-triggered Standard Function Calls.
  • Use the Environment API for programmatic access.

Insights via Account Management

You can also track your usage in Account Management. Go to Account Management > Subscription > Overview > Cost and usage details > Usage summary and select the Standard Function Calls capability.

Insights via billing usage events

Billing usage events (billing_usage_event) are system events emitted by Dynatrace that capture already-calculated, billable usage for DPS capabilities. They are the most reliable source for building cost dashboards and allocation reports.

Standard Function Calls

You can use DQL to filter for events, for example with event.type == "AppEngine Functions - Small", to find Standard Function Call invocations, as shown in the examples below.

Example query: See Standard Function Call invocations by function type

The following DQL query provides an overview of daily Standard Function Call invocations by function type:

fetch dt.system.events, scanLimitGBytes: -1
| filter event.type == "AppEngine Functions - Small" AND event.kind == "BILLING_USAGE_EVENT" AND (billing_type == "BILLABLE" OR isNull(billing_type))
| fieldsAdd data = if(matchesPhrase(function.type, "AD_HOC"), "Ad-hoc", else: if(matchesPhrase(function.type, "ACTION"), "Actions", else: if(matchesPhrase(function.type, "STANDARD"), "App functions")))
| summarize billed_invocations = takeAny(billed_invocations), by:{timestamp=bin(timestamp, 1d), event.id,data}
| summarize invocations = sum(if(billed_invocations,billed_invocations,else:1)), by:{data, timestamp}
| sort timestamp desc, invocations desc
Example query: See which users and apps use Standard Function Calls

The following DQL query provides details on users and apps using Standard Function Calls:

fetch dt.system.events, scanLimitGBytes: -1
| filter event.type == "AppEngine Functions - Small" AND event.kind == "BILLING_USAGE_EVENT" AND (billing_type == "BILLABLE" OR isNull(billing_type))
| summarize billed_invocations = takeAny(billed_invocations), by:{startHour = bin(timestamp, 1h), event.id, user.email, caller.app.id}
| summarize Invocations = sum(if(billed_invocations,billed_invocations,else:1)), by:{User = user.email, Calling_App = caller.app.id}
| sort Invocations desc

AI-triggered Standard Function Calls

When a Standard Function Call is invoked by agentic AI, it has a specific billing usage event that identifies it as such. These events share the same billing unit (invocations), but AI Function Standard Calls carry additional fields for tracing the call back to the AI request that triggered it.

For the complete field reference, see AI Function Standard Call billing usage in the Semantic Dictionary.

AI Function Standard Call fields
FieldDescription

event.type

  • "AppEngine Functions - Small" for Standard Function Calls,
  • "AI Function Standard Call" for AI-triggered Standard Function Calls.

Filter on the appropriate value depending on which invocations you want to query.

billed_invocations

The number of billed invocations for the AI Function Standard Call, metered and billed like a Standard Function Call.

tool

The tool invoked, for example execute-dql, get-problem-by-id, or timeseries-forecast.

tool.category

standard: Marks the record as a Standard Call.

caller.service.id

MCP_GATEWAY: These tool calls run through the MCP gateway.

session_id, conversation_id

Identify the MCP session and conversation the call belongs to. For details, see AI Units billing usage.

workflow.id, workflow.execution.id

Set when a Workflow triggered the call: the workflow definition and the specific run.

Example query: See AI Function Standard Calls by tool and caller type

The following DQL query summarizes AI Function Standard Call invocations by tool and caller type.

fetch dt.system.events, scanLimitGBytes: -1
| filter event.kind == "BILLING_USAGE_EVENT"
| filter event.type == "AI Function Standard Call"
| summarize standard_calls = sum(billed_invocations), by:{tool, caller.type}

Insights via API

You can query metrics via the Environment API - Metrics API v2.

FAQs

How are AI Function Standard Calls billed?

The same way as any other Standard Function Call: by the number of billed invocations. The only difference is that the billing usage event is recorded under event.type == "AI Function Standard Call" instead of AppEngine Functions - Small, and carries additional fields (such as session_id and conversation_id) for tracing the call back to the AI request that triggered it.

Related topics

  • Agentic AppEngine overview (DPS)
  • AppEngine
  • App functions
  • Understand and manage AI Units consumption (DPS)
  • Dynatrace MCP server
  • Dynatrace pricing
Related tags
Dynatrace PlatformSoftware DeliveryAI Observability