Dt Platform Costs

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 scan 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

This skill queries and analyzes existing consumption data. It is not a DPS pricing guide — for billing concepts, see the official documentation.

Agent Instructions

Intent Mapping

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.

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.

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