FAQ¶

Plan Selection and Billing¶

Can Session Replay have its own storage duration (for example, 3 or 7 days) configured independently, like logs?

This depends on your plan:

• Commercial Plan: No. The storage policy for Session Replay data is tied to Real User Monitoring (RUM) and always follows the RUM storage policy (3/7/14 days); it cannot be adjusted independently.
• Deployment Plan: Yes. You can configure a separate storage policy for Session Replay in the Management Console.

My business is mainly in the China region, but some users are overseas. Should I choose CNY or USD for billing?

TrueWatch has two billing systems:

The currency choice affects invoice type and payment method and must be determined when registering the Workspace. If your business spans multiple regions, we recommend creating separate Workspaces for each region and settling each in the local currency.

I have been billed in CNY for some time. Can I switch to USD?

You cannot switch directly through self-service. Because this involves different billing systems (China Region vs. Global Region) and account migration, you need to:

1. Contact your Account Manager to submit a currency switch request.
2. Historical invoices for the original Workspace remain settled in CNY.
3. New charges incurred after the switch are settled in USD.

Before switching, we recommend settling any outstanding balance in your CNY account and evaluating the impact of exchange rate fluctuations on your budget.

My log volume is large but access frequency is low. Which is more cost-effective, Commercial Plan or Enterprise Plan?

This depends on the ratio between your write traffic and total storage volume:

• Commercial Plan: Billed by write volume (entry count or traffic), plus tiered rates based on storage duration. Suitable for scenarios with high data access frequency, long-term storage, and frequent queries. If you only need short-term storage (3-7 days), Commercial Plan is usually more economical.

• Enterprise Plan: Billed by compressed write traffic plus total storage volume, regardless of storage duration. Suitable for scenarios with extremely large log volumes but low query frequency that require long-term archiving. Even with 360 days of storage, the unit price does not increase in tiers with duration, but you must keep paying for the total storage volume.

If your data has a high compression ratio (for example, text logs can be compressed to 20%) and your storage period is 30 days, contact your Account Manager to evaluate an Enterprise Plan.

Data Observability Billing¶

How is Data Observability billed?

• Commercial Plan: Billed by the number of new valid Runs per day, in units of 1,000 Runs/day. The unit price varies with the selected storage duration. For specific prices, see Commercial Plan Billing Details.
• Enterprise Plan: Compressed write traffic and actual storage volume are billed under the existing write traffic and data storage fees, following the current Enterprise Plan billing standards.

If the same run reports status multiple times, will it be billed repeatedly?

Each job run is billed only once. Multiple status reports during a run do not increase the number of billable Runs.

Data Storage Policy Changes¶

I shortened the log storage duration from 14 days to 3 days. Why didn't my bill decrease immediately?

This is caused by the rolling billing mechanism. After a policy change for non-metric data (logs, Traces, etc.):

1. Historical data: retained until it reaches the original storage duration (14 days) and billed at the higher unit price of the original policy.
2. New data: billed immediately at the lower unit price of the new policy.

Therefore, it takes a 14-day transition period for costs to decrease. If you need to reduce costs immediately, you must manually delete historical data (which will result in data loss).

When the storage policy for metric data is changed, old data is deleted immediately and costs drop immediately, but the data cannot be recovered.

If I modify the storage policy multiple times in one day, which modification takes effect?

The first modification of the day takes effect immediately; subsequent modifications take effect the next day.

Example scenario:

• 09:00: Change logs from 14 days to 7 days → takes effect immediately; billing at the 7-day unit price starts that day.
• 15:00: Change logs again from 7 days to 3 days → takes effect at 00:00 the next day; today is still billed at the 7-day rate.

Avoid making multiple adjustments in one day to prevent confusing billing records.

Why are metric data and non-metric data handled differently after a storage policy change?

• Metric data: The change takes effect immediately. Old data is deleted immediately and cannot be recovered. This is because metric data is large in volume and updated frequently, so the system uses immediate cleanup.

• Non-metric data (logs, Traces, Profiles, RUM, etc.): After the change, new data is billed under the new policy, while old data is retained until the end of the original storage period. This is because non-metric data usually has audit value, and data continuity must be maintained.

Shortening the storage duration for metric data reduces costs immediately, but for non-metric data you must wait through the transition period to see the full cost reduction.

After enabling custom multi-index, why can I only change the storage policy of the "default" index? What about the other indexes?

Each index is bound to its own storage policy. To change it:

1. Go to Logs > Index Management.
2. Set the storage duration for each custom index separately.
3. Each index is billed according to its own duration policy.

If a custom index has no policy configured, it inherits the policy of the default index by default. However, billing is calculated independently for each index and is not combined.

Billing Items and Calculation Logic¶

In Commercial Plan, logs can be billed by entry count or by write traffic. When is switching more advantageous?

The key factor is the average size of a single log entry:

• Entry < 1 KB: Billing by entry count is usually better (1 GB is roughly 1 million entries; billing by count may cost only 1 unit).
• Entry > 10 KB (ES) or > 2 KB (SLS): Billing by traffic is better, preventing large logs from being split into multiple billable entries.

If a Monitor's detection interval is set to 30 minutes, is Triggers usage counted as 2 (30/15) or 6 (base 5 + 1 for the excess)?

The latter is correct. The billing formula is:

total count = base count for the detection type + ⌈(detection interval - 15 minutes) / 15 minutes⌉

For Sudden Change Detection (base count 5) with a 30-minute interval:

• Base: 5
• Excess portion: (30-15)/15 = 1, rounded up to 1
• Total: 6

What usage is generated when an AI Monitor runs a detection?

Each time an AI Monitor runs a detection, the following two types of usage are generated and counted separately:

• Triggers: counted as 1 Trigger.
• AI Credits: deducted according to the Credits actually consumed by this detection.

The "per-detection credit budget" in Advanced Settings controls the credit consumption of a single detection; it does not mean that a fixed amount is deducted every time.

How is Triggers usage calculated for different Smart Monitoring types?

Different types are counted according to the following rules:

• Host/Log/Application intelligent detection: 10 per run
• RUM intelligent detection: 100 per run
• AI Smart Monitoring: 100 per run

Each time AI Smart Monitoring runs a detection, Credits are also deducted based on the actual consumption of the AI analysis. Triggers and Credits are counted separately.

Trace data is sometimes billed by Trace and sometimes by Span. How can I predict my bill?

The system automatically selects the more favorable method:

• If the number of Traces ≥ the number of Spans / 10, billing is by Trace (per million Traces).
• Otherwise, billing is by Span (per 10 million Spans).

You can check the Service Overview in Application Performance Monitoring (APM). If the average number of Spans per Trace is > 10, you will most likely be billed by Span; if < 10, you will be billed by Trace. You can control the number of Traces by adjusting the sampling strategy, thereby affecting the billing method.

Every time an escalation policy notification is triggered, 100 Triggers are deducted. Is the deduction applied every time a notification is sent?

Yes. Each time an escalation policy is triggered, 100 Triggers are recorded when the notification is sent.

In Commercial Plan, why do Events and self-hosted Synthetic Test data use the storage policy of the log default index by default?

Because these two types of data are physically stored in the default index of Logs:

• Event data (generated by Monitors, SLOs, and Intelligent Inspection) is stored in the default index.
• Self-hosted Synthetic Test data is reported through DataKit and is also stored in the default index.

Therefore, their storage duration and billing unit price inherit the configuration of the default index. If you need separate adjustments, there is currently no way to set an independent storage policy directly for Events or self-hosted Synthetic Tests; you can only affect them indirectly by adjusting the duration of the default index.

Exception: Synthetic Test data from the TrueWatch node is also stored in the default index, but Synthetic Test execution itself is billed separately by the number of tests, which is a different dimension from storage billing.

Data Splitting and Compression Billing¶

Oversized logs have different splitting thresholds in ES and SLS storage. How do I calculate my actual entry count?

Calculate separately according to your storage type:

ES storage:

• Entry ≤ 10 KB: counted as 1 entry
• Entry > 10 KB: billable entries = ⌈actual size / 10 KB⌉

Example: a 15 KB log counts as 2 entries; a 25 KB log counts as 3 entries

SLS storage:

• Entry ≤ 2 KB: counted as 1 entry
• Entry > 2 KB: billable entries = ⌈actual size / 2 KB⌉

Example: a 3 KB log counts as 2 entries; a 5 KB log counts as 3 entries

A Session Replay Session lasts 5 hours and is split into 2 billing units. Are these two units billed consecutively or allocated by actual active time?

Billing is based on integer multiples rounded up, regardless of time distribution:

billing units = ⌈time_spent / 4 hours⌉ = ⌈5/4⌉ = 2 units

These 2 units are included in the day's bill at one time; they are not billed in hourly segments. Even if the Session has 1 hour of inactivity in the middle, as long as the time_spent field shows a total duration of 5 hours, it is billed as 2 units.

When a Profile file exceeding 300 KB is split, are the split entries stored separately, or is the split only for billing?

The split is for billing only; storage still uses the original file. The system splits large Profile files into multiple records for indexing and billing (1 entry per 300 KB), but at the storage layer they remain associated as a single Profile collection. This is to prevent oversized single records from affecting query performance, while keeping billing proportional to storage resource consumption.

What does "take the larger of PV and PV/100" mean in PV billing?

This is a floor billing mechanism for low-traffic scenarios:

• If the PV count for the day is 500, then 500/100 = 5; the larger value, 500, is used, so billing is for 500.
• If the PV count for the day is 50, then 50/100 = 0.5; the larger value, 50, is used, so billing is still for 50 (not 0.5 or 1).

Only when the PV count > 100 does PV/100 exceed 1, in which case the PV count itself is used. This rule mainly avoids precision issues with extremely low traffic and has no practical impact on normal business traffic (>100 PV/day).

In Sensitive Data Scanning, why do multiple fees arise when multiple fields in the same log entry are masked?

Because billing is based on scan traffic at the field level:

• Each field that requires masking is counted at its raw traffic separately.
• Even if these fields belong to the same log entry, they are billed separately.

Example: a 1 KB log entry contains 3 sensitive fields. Scan billing is calculated based on the total raw traffic of the 3 fields (which may be > 1 KB, depending on field content size), rather than the 1 KB of the single log entry.