Use this skill when the user asks to "check data usage", "list TCO policies", "reduce Coralogix costs", "optimize observability spend", "lower our logging bill", "data budget exceeded", "TCO policy", "retention tier", "archive storage", "ingestion costs", "frequent search vs archive", "why is our bi

Cost Optimization Skill Use this skill when investigating or reducing Coralogix data costs. It covers the full cost management lifecycle: measuring current spend, reviewing TCO policies, adjusting retention periods, and configuring archive storage for cold data. CLI Commands Command Subcommands Purpose cx usage summary , daily , logs count , spans count , export status , capabilities , query Measure current data consumption and billable usage cx tco list , get , create , update , delete , reorder , test , settings , settings update Manage TCO (Total Cost of Ownership) policies cx retentions list , update , activate , status Manage data retention periods cx archive logs get , set Configure logs archive target cx archive metrics get , create , update , enable , disable , validate Configure metrics archive storage cx metrics query <promql (positional), time Query billing and usage metrics via PromQL (instant) cx metrics query range <promql (positional), start / end Query billing and usage metrics via PromQL (range) Key flags: All commands support o json for structured output and p <profile for profile selection cx usage daily accepts type processed gbs units evaluation tokens and start / end time filters cx usage summary accepts start / end time filters cx usage logs count and cx usage spans count accept start / end time filters, defaulting to the last 24h, plus resolution (default 1h ), subsystem aggregation , application aggregation , and repeated param KEY=VALUE for API filter query params Data usage summary and count endpoints are documented as newline delimited JSON over Accept: text/event stream ; the CLI handles that transport and normalizes count chunks into .result.logsCount[] or .result.spansCount[] . cx usage capabilities is the required first step: it returns the labels, measurements, units, and request limits that the public Data Usage Query API currently supports for the selected tenant cx usage query is the required second step: submit only a JSON request derived from the immediately preceding capabilities response with exactly one of query '<json ' or from file <path ( from file reads stdin) cx tco create/update , cx retentions update , cx archive logs set , cx archive metrics create/update/validate use from file <path (or for stdin) Authoritative Billable Usage Queries For billable totals, quota units, plan consumption, or a supported usage breakdown, use this mandatory two step workflow: 1. Run cx usage capabilities in the current session. 2. Build and run cx usage query using only that response. Do not call cx usage query first and do not guess labels, measurement kinds, units, filter values, intervals, or request limits. They are tenant specific and can change. Load [ references/data usage query api.md ](references/data usage query api.md) before creating the query body. It defines the capability and response schemas, valid interval forms, and limits. Cost Investigation Workflow Follow these steps to diagnose and reduce costs: Step 1: Measure Current Usage For billable totals, quota units, plan consumption, or supported breakdowns, first follow the mandatory two step workflow above: Build usage query.json only from the immediately preceding capabilities response. Do not use the legacy commands below as a substitute for an authoritative billing answer. For a legacy consumption overview and log/span record counts, use: Identify which data types consume the most volume. Use jq to sort: Step 2: Review TCO Policies TCO policies control which logs go to Frequent Search (expensive, fast) vs. Archive (cheap, slower). Check if high volume, low value logs are on Frequent Search: Step 3: Check Retention Settings Long retention periods increase storage costs. Identify indices with unnecessarily long retention. Step 4: Check Archive Configuration Verify that archive storage is configured for cold data. If no archive is set up, that's a cost saving opportunity. Step 5: Recommend Optimizations Based on findings, recommend changes in priority order (highest impact first). Common Optimization Patterns Symptom Diagnosis Command Optimization High volume low value logs cx usage summary o json Move to archive tier via cx tco create from file policy.json Long retention on cold data cx retentions list o json Reduce retention with cx retentions update from file No cold storage configured cx archive logs get o json Enable archive with cx archive logs set from file yes (after user approval) Expensive metrics not queried cx archive metrics get o json Enable metrics archiving with cx archive metrics create from file yes (after user approval) jq Examples Usage Analysis TCO Policy Analysis Retention Review Archive Status Applying Changes IMPORTANT: NEVER pass yes without explicit user approval. All write operations across archive, TCO, and retentions require interactive confirmation and the yes flag to execute non interactively. Before executing any write operation, describe the exact change to the user and wait for their approval before passing yes . Read only mode: Use read only (or CX READ ONLY=1 ) to safely explore cost data without risk of accidental writes. All query commands (usage, tco list/get, retentions list, archive get) work normally in read only mode. Agent mode: When running inside an AI agent, cx fails fast on write operations instead of hanging on a stdin prompt. Get user confirmation first, then re run with yes . When modifying TCO policies, retention, or archive: 1. Template from existing: Get the current configuration as JSON, modify it, then apply: 2. Verify after changes: Re run the diagnosis commands to confirm the change took effect. 3. TCO policy ordering matters: Use cx tco reorder from file to set priority order. Policies are evaluated top to bottom; the first match wins. Metrics Based Cost Analysis The cx usage API gives summaries, but for billing accurate analysis, anomaly detection, and breakdown by pillar/feature, query the customer metrics exporter via PromQL. Key Metrics Metric Meaning Query suffix cx data usage units Daily billable usage in units (canonical billing metric) No total cx data plan units per day Current daily plan quota in units (snapshot) No total cx data usage payg units Daily overage/PAYG usage in units No total cx data usage total Processed data size in bytes total cx data usage tokens total AI evaluation tokens total cx data usage samples total Processed metric samples total Concept to Metric Mapping Billing / plan usage / consumption cx data usage units + cx data plan units per day Processed bytes / data volume cx data usage total AI evaluation tokens cx data usage tokens total Metric samples cx data usage samples total Overage / PAYG cx data usage payg units Common PromQL Queries UTC Day Bucketing Rules All usage metrics accumulate from UTC midnight and reset at 00:00 UTC : An instant query during the day returns "today so far" For completed day totals, use the last sample before midnight Never subtract values across a UTC midnight boundary For weekly/monthly analysis, derive completed daily totals first, then roll up Exclude the current partial UTC day when computing trends or averages Anomaly Detection When investigating usage anomalies: 1. Compare completed UTC days (exclude current partial day) 2. Break down by: measurement type pillar entity type priority feature group id application name subsystem name 3. Prefer same weekday comparisons for seasonal traffic 4. Use cx data usage units for billing anomalies, cx data usage total for volume anomalies Breakdown Labels Usage metrics support these grouping dimensions: pillar , entity type , priority , measurement type , feature group id , feature id , application name , subsystem name . Key Principles Measure before changing always run usage/summary commands before modifying policies Use o json with jq structured output enables precise analysis Verify changes re query after every modification to confirm it took effect Multi profile awareness use p <profile or all profiles to compare costs across environments Template from existing get current config as JSON before creating or updating TCO is the biggest lever moving logs from Frequent Search to Archive tier has the largest cost impact Related Skills cx telemetry querying investigate what data is being ingested (query logs, metrics, and spans to identify high volume sources) Reference Files [ references/data usage query api.md ](references/data usage query api.md) capabilities and query schemas, interval rules, limits, and response interpretation

cx-cost-optimization