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.

Query and analyze Dynatrace platform billing and cost data using DQL. All data lives in dt.system.events with event.kind == "BILLING_USAGE_EVENT", segmented by event.type (consumption category).

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)

This skill applies exclusively to DPS-licensed environments. All billing event types, unit conversions, the public rate card, and cost estimation workflows are DPS-specific.

NEVER apply this skill's unit conversions or cost estimates to classic license models (host units, DDUs, DEM units, ASUs). If the user mentions classic licensing terms or units, explain that this skill covers DPS only and refer them to https://docs.dynatrace.com/docs/license/monitoring-consumption-classic for details.

Licensing / Entitlement Questions — STOP

Triggers: "Am I allowed to use X?", "Is X licensed?", "Is X in my subscription?", "Do I have entitlement for X?"

STOP — do not execute any DQL queries. Billing usage events record active consumption only, not subscription entitlements. Absence of billing events means not currently consumed, NOT unlicensed. Do not infer entitlement from usage patterns or their absence. Respond directly without queries and direct to Account Management > Subscription > Pricing.

❌ 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

Triggers: "How does billing work?", "How are costs calculated?", "Explain DPS billing", "How is X billed?", "What is the billing model?", "How does DPS pricing work?", "How does Dynatrace charge?", "Explain the rate card"

STOP — do not answer from this skill's content. The normalization weights, unit conversion formulas, and lookup values in this skill are DQL-generation tools, not user-facing billing education. Presenting them as an explanation of DPS billing is wrong — they are internal ranking aids, not contracted rates.

Your entire response must be ONLY the two sentences below — nothing else. Do not list capabilities or units, do not describe metering, included volume, or normalization, do not add a "How costs are calculated" section, and do not append the Getting Started menu or a list of example prompts beyond the single one shown:

❌ 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 cost attribution, workflow total cost (4 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

Usage vs Cost Distinction

Only add cost information when the user explicitly asks for it. Units are incomparable across categories — cost normalization is the only way to rank or sum them.

When rate card is present, the "cost" path uses contracted currency amounts. cost_weight and Full Inline Lookup are not used in the rated path.

Preview types: Only capabilities explicitly marked as preview in cost-estimations.md are preview — never infer preview status from zero usage.

Cost Ranking Rules

When producing a cost answer for any intent involving cost ranking or cost drivers (cost drivers, cost trend, workflow cost, query cost attribution, cost investigation, cost spike):

0. Resolve price source — run the pre-flight from cost-estimations.md § Pre-flight Detection. Precedence: user-provided rate (for that capability) > rate card > normalization weights.

   • Rate card readable → rated path: append the Rate Card Join Snippet after the | summarize billable_usage step; sort by isNull(estimated_cost) asc, estimated_cost desc (unpriced types last). For output rules and validity warnings, see cost-estimations.md § Output Rules for Rated Path.
   • Rate card absent/unreadable → unrated path: append the Full Inline Lookup for Cost Rankings; sort by cost_weight desc. NEVER multiply normalization weights mentally — values span orders of magnitude where silent arithmetic errors are undetectable. Exception — query cost attribution: rank by billable_usage, no cost_weight (why); the unrated ℹ️ disclaimer still applies. Exception — single capability: when the question covers exactly one capability, there is nothing to rank. Skip the Full Inline Lookup and do not compute cost_weight. Convert to native units in DQL as in the Usage row of Usage vs Cost Distinction. Within a single event.type, unrated rankings sort by the billed field in DQL (the weight is constant); the rated path appends the rate-card join for currency. How to mention the check: Pre-flight Detection.

1. Compute cost measure in DQL — rated path: estimated_cost in contracted currency (from the rate-card join). Unrated path: cost_weight (from the Full Inline Lookup, an internal ranking value — never display as a dollar amount). Finish unrated queries with | filter isNotNull(cost_weight) | sort cost_weight desc | fields event.type, capability_usage, cost_weight.

   (Note: cost_weight is included in DQL output for sorting — Step 2 drops it from the user-facing table before presenting.)

2. Present rankings — DQL results arrive pre-sorted.

   • Rated: four columns: rank, capability name, native units, estimated cost labeled "estimated cost (from BUE) [<currency_code>]". For BUE types not in the rate card, show native units only (leave cost column empty — do not show $0).
   • Unrated: drop cost_weight and present only: rank number, capability name, usage in native units (e.g. GiB, GiB-hours, sessions, data points). Never include a cost, weight, or dollar column. For percentage questions, output a share-of-total table (see Cost share / percentage above).

3. Disclaimer FIRST — applies to multi-capability results only (2+ capabilities, or any ranking or percentage table, including hosts/apps/cost centers within one capability). Make the disclaimer the first line of the answer — no lead-in. The final message starts with the > ℹ️ line itself: no status sentence ("I have all the data…", "Here are the results"), heading or --- before it, and no second note about the price source after it. Copy the applicable text verbatim:

   • Rated: > ℹ️ Estimated costs from BUE. For authoritative figures, see Account Management > Subscription > Overview > Cost and usage details.
   • Unrated: > ℹ️ Rankings show relative spend — for actual cost figures, see Account Management > Subscription > Overview > Cost and usage details.

   For single-capability results: omit the disclaimer entirely — except in user-provided rate mode, where the required warning applies even for single-capability results. A single-capability answer is the usage table only: add no ℹ️ line and no sentence about rate cards, their validity, dollar amounts, or why a cost figure is unavailable.

   For zero-rated results: determine disclaimer based on current path (rated/unrated).

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" anywhere else. 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 billable metric keys carry the most data points, then decide together what to optimize.

   "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; never run more than 14 days per query — platform data is high volume, and the Metrics/Traces Ingest included-volume deduction breaks silently on longer windows (one 31-day window inflated billable Traces Ingest 2.7×). For a month or longer, split into ≤ 14-day windows and sum — see billing-capabilities.md § Longer Timeframes.
3. Use explicit UTC midnight boundaries for billing totals, and, only for portal reconciliation or exact-totals requests, tell the user in one sentence why (a rolling window's partial first day won't match the portal) — 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 § Single-Query Details 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.
• Log Import bills at import time — imported historical logs share the log ingest event.type and are billed in the window the import job ran, not the period the records came from. Uncommon, but worth ruling out (isNotNull(dt.job.id)) for an unexplained log-ingest jump. See billing-event-types.md § Log Ingest Sources.
• 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 § QEE Exceeds BUE.
• Rate card is optional — costs shown as estimated amounts in the contracted currency only when a rate card is present and readable. Without one, all cost outputs are relative rankings (native units or cost-weight).
• Rate card scope — not all BUE types may have a rate card entry. Types without a price show native units only.