dt-platform-costs

⛔ FIRST — CHECK SCOPE BEFORE DOING ANYTHING ELSE. This skill only queries and analyzes a tenant's actual consumption data. It does not teach billing concepts. If the user is asking how billing/pricing works, how costs are calculated, what units / normalization weights / the rate card mean, or any conceptual "explain" question about DPS billing — this skill does not answer it. See Billing Concepts — STOP and respond with only the prescribed two-sentence documentation redirect. Do not explain units, weights, included volume, or methodology, and do not show the Getting Started menu. Continue into the rest of this skill only when the user wants to query or analyze their own tenant's numbers.

dt.system.events

event.kind == "BILLING_USAGE_EVENT"

event.type

Scope boundary: This skill covers Dynatrace platform billing (DPS consumption). For AWS cloud infrastructure costs ingested via FOCUS, use

dt-biz-cloud-costs

instead.

Dynatrace Platform Subscription (DPS)

Licensing / Entitlement Questions — STOP

❌ Query billing events → no results → conclude "not licensed" — WRONG (absence ≠ no entitlement) ✅ Respond immediately: "Entitlement data is not available via DQL. Check Account Management > Subscription > Pricing."

Billing Concepts — STOP

❌ Explain metering / units / normalization weights, then offer the Getting Started menu — WRONG (that is the exact failure to avoid) ✅ Respond with only: "For how DPS pricing and billing work, see the Dynatrace Platform Subscription documentation. If you'd like to analyze your tenant's actual consumption, ask e.g. 'What are my top cost drivers for the last 7 days?'"

When to Use This Skill

• Usage Overview — DPS consumption breakdown by capability, unit conversion, cross-capability comparison
• Cost Estimation — Cost-normalized usage comparison and relative spend ranking, daily cost trends, spending spikes
• Cost Investigation — Step-by-step drill-down into cost drivers, query scan cost attribution, workflow total cost (3 signals)
• Chargeback / Showback — Cost center and product attribution, team-level billing
• Included Volume — Metrics/Traces Ingest baseline deduction, billed vs. total usage

Agent Instructions

Intent Mapping

cost_weight desc

capability_usage

Usage vs Cost Distinction

• "Usage" → Unit conversion only, no cost estimates. Label with unit from Cost Normalization Weights (or billing-event-types.md for preview types).
• "Cost" → Unit conversion + compute

  cost_weight

  in DQL (via the Full Inline Lookup) for internal ordering/aggregation only. Never display

  cost_weight

  as a dollar amount. Omit from rankings for types not in the normalization table.
• "Cost drivers" → Ranked list sorted by

  cost_weight

  (computed in DQL via the Full Inline Lookup). Output columns: rank, capability name, usage in native units. Drop

  cost_weight

  before presenting — it never appears in any column, label, or sentence.
• "Cost share / percentage" → Compute share-of-total using normalized weights (usage × Normalization Weight per capability). Present as a percentage table. Use the standard ℹ️ disclaimer from Cost Ranking Rules step 3 — do not add any additional caveat or note.
• "User-provided rate" → If the user supplies a contracted rate (e.g. "$0.15/GiB for Log Ingest"), use that rate for that capability and display actual USD for it. All other capabilities show usage-only (no cost). Disclaimer: ⚠️ Calculated using your provided rate of $X/unit. For all capabilities without a provided rate, only usage is shown. For authoritative totals, refer to Account Management > Subscription. Never infer or assume rates — only accept them when the user explicitly states them.

Cost Ranking Rules

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

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."

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.