Dt Platform Costs

Cost Ranking Rules

When any intent involves cost ranking or cost drivers (cost drivers, cost trend, workflow cost, query cost attribution, cost investigation, cost spike):

1. Compute cost_weight in DQL — run the base usage queries (Queries 1–4 from billing-capabilities.md) up through the | summarize billable_usage step, then immediately append the Full Inline Lookup for Cost Rankings. The Full Inline Lookup handles unit conversion and cost weighting in one step — do not also apply the Unit Conversion Lookup from billing-capabilities.md; it is redundant and a chained lookup replaces all existing lookup.* fields, which breaks the cost-weight computation. Finish the query with | filter isNotNull(cost_weight) | sort cost_weight desc | fields event.type, capability_usage, cost_weight. NEVER multiply normalization weights mentally — values span orders of magnitude where silent arithmetic errors are undetectable.

2. Present rankings, not dollar amounts — the DQL results arrive pre-sorted. Drop the cost_weight column and present only: rank number, capability name, usage in native units (e.g. GiB, GiB-hours, sessions, data points — whatever unit that capability measures in). Never include a cost, weight, or dollar column. Example output for "top 5 cost drivers":

   1. Log Management & Analytics - Ingest & Process  62.3 TiB
   2. Full-Stack Monitoring                           2,366,800 GiB-hours
   3. Real User Monitoring                            51.5M sessions
   4. Infrastructure Monitoring                       847,200 host-hours
   5. Metrics - Ingest & Process                      18.2B data points

   For percentage questions, output a share-of-total table (see Cost share / percentage above). Never show raw USD estimates unless the user has provided their own contracted rate.

3. Disclaimer BEFORE results — applies to multi-capability results only (2+ capabilities, rankings, or percentage table). Copy this text verbatim — do not paraphrase or rephrase it:

   ℹ️ Rankings show relative spend — for actual dollar figures, see Account Management > Subscription > Overview > Cost and usage details.

   For single-capability results (exactly one capability, no cross-capability comparison): omit the disclaimer entirely — the result is straightforward billing data with no normalization involved.

   Exception: if the response is in user-provided rate mode, include the warning required for that mode even for single-capability results. The single-capability omission applies only to the standard multi-capability ranking disclaimer above.

4. No supplementary rate-card notes — the prescribed disclaimer above is the only place normalization methodology may be referenced. Never add sentences like "These numbers are based on the public DPS rate card" or "based on public list prices" anywhere else in the response. This does not suppress the required warning for user-provided rate mode.

Getting Started

When a user asks a generic or open-ended question about costs, usage, or what the skill can do, respond with the menu below. Do not run any DQL queries yet — wait for the user to choose a direction.

Here's what you can explore:

1. Cost breakdown — See which capabilities are driving spend, ranked by relative cost.

   "What are my top cost drivers for the last 7 days?"

2. Usage overview — Full picture of DPS consumption across all capabilities, in native units.

   "Give me an overview of our platform usage across all capabilities."

3. Spike investigation — Attribute a cost spike to its source (dashboard, workflow, detector).

   "My log query cost spiked last week — which source is causing it?"

4. Chargeback / showback — Break down cost by team, product, or cost center.

   "Show me a cost breakdown by cost center for the last 30 days."

5. Metrics optimization — If metrics ingest is a top cost driver, drill into which metric keys are billable and reduce the highest-cost ones.

   "Which metrics are driving our ingest cost? Help me optimize."

Which of these matches what you're trying to do?

Prerequisites

• Access to a Dynatrace environment
• DQL query permissions on dt.system.events
• Load dt-dql-essentials before writing queries — covers DQL syntax, type handling, and field discovery via dt.semantic_dictionary.fields

Knowledge Base Structure

Quick Start

fetch dt.system.events, from: -7d
| filter event.kind == "BILLING_USAGE_EVENT"
| summarize event_count = count(), by: {event.type}
| sort event_count desc

Best Practices

1. Always filter by event.kind first — avoids scanning irrelevant events.
2. Start with 7d time ranges — platform data is high volume.
3. Use explicit UTC midnight boundaries for billing totals — see billing-capabilities.md § Billing Timeframe Boundaries.
4. Never use ~ for approximation — use ≈ or "approximately" (bare ~ creates Markdown strikethrough).
5. Empty results? — Run the discovery query above to verify available event types.
6. count() fans out — confirm one-row-per-thing before counting — both QUERY_EXECUTION_EVENT (one row per bucket touched per DQL statement) and WORKFLOW_EVENT WORKFLOW_EXECUTION (≈2 rows per run: start + completion) over-count when you count() them. For DQL-statement volume use countDistinct(query_id); for workflow run count and frequency use countDistinct(dt.automation_engine.workflow_execution.id) on WORKFLOW_EXECUTION — never bare count(). Never write "ran N times" or compute a per-second/per-minute rate from any raw count(). See query-cost-attribution.md § Step 3 and workflow-total-cost.md § How Often Did the Workflow Run.
7. Never use entity-model functions — entityName() (and any function that takes a dt.entity.* field to resolve entity metadata) is deprecated. Present raw dt.entity.* IDs (e.g. HOST-1A2B3C) in results. Grouping or counting on the ID (by: {dt.entity.host}, countDistinct(dt.entity.host)) is fine — that uses the ID as a plain value. See entity-cost-drilldown.md § Entity IDs in Results.

Limitations

• No universal usage field — each event type uses a different billed unit. Cannot sum across categories without cost normalization.
• Normalization weights ≠ contract rates — see Cost Ranking Rules. Rankings are relative; for authoritative figures use Account Management.
• Included volume — Metrics/Traces Ingest include a host baseline (≈14 days max). See billing-capabilities.md § Included Volume.
• Cost attribution is optional — only populated when configured; Retention events often lack entity references.
• Zero-rated queries — Certain queries may be zero-rated based on execution context (user, apps, queried data). These produce QEE records but no corresponding BUE. A gap between QEE scanned_bytes and BUE billed_bytes totals indicates zero-rated usage, not a pipeline issue. See query-cost-attribution.md § Investigating QEE↔BUE Mismatches.