FAQ¶

Version Selection & Billing¶

Can Session Replay have its own 3-day or 7-day retention period like logs?

It depends on your plan:

• Commercial Plan: No. Session Replay data retention is tied to Real User Monitoring (RUM) and uses the RUM retention policy (3/7/14 days). It cannot be adjusted separately.
• Deployment Plan: Yes. You can configure Session Replay retention independently in the Admin Console.

My business is mainly in China, 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 a workspace. If your business spans multiple regions, we recommend creating separate workspaces in each region and using the local currency for billing.

I've been using CNY billing for a while. Can I switch to USD?

No, you cannot switch directly via self-service. Because it involves different billing systems (China vs. Global) and account migration, you need to:

1. Contact your account manager to submit a currency switch request
2. Historical bills of the original workspace remain in CNY
3. Charges incurred after the switch will be billed in USD

We recommend settling any outstanding CNY balance before switching, and evaluating the impact of exchange rate fluctuations on your budget.

I have a large volume of logs but low access frequency. Which is more cost-effective, Commercial or Enterprise Plan?

It depends on the ratio of "write traffic" to "total storage":

• Commercial Plan: Billed by write volume (count or traffic) + storage duration tier. Suitable for scenarios with frequent data access, long storage, and many queries. If only short-term storage (3–7 days) is needed, the Commercial Plan is usually more economical.

• Enterprise Plan: Billed by compressed write traffic + total storage amount, independent of storage duration. Suitable for scenarios with massive log volumes, low query frequency, and long-term archival needs. Even if stored for 360 days, the unit price does not increase with time, but you pay continuously for the total storage amount.

If your data has a high compression ratio (e.g., text logs compress to 20%) and the retention period is 30 days, we recommend contacting your account manager to evaluate the Enterprise Plan.

Data Retention Policy Changes¶

I shortened log retention from 14 days to 3 days. Why didn't the bill drop immediately?

This is due to the rolling billing mechanism. For non-metric data (logs, traces, etc.), after a policy change:

1. Historical data: Continues to be retained until the original retention period (14 days) is reached and is billed at the higher unit price of the original policy.
2. New data: Immediately billed at the lower unit price of the new policy.

Therefore, the cost decrease will have a 14-day transition period. To reduce costs immediately, you would need to manually delete historical data (which will result in data loss).

For metric data, old data is deleted immediately after a policy change, and the cost drops immediately, but the data is unrecoverable.

If I modify the retention policy multiple times on the same day, which one takes effect?

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

Scenario example:

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

We recommend avoiding multiple adjustments within a single day to prevent confusing billing records.

Why do metric and non-metric data behave differently after a retention policy change?

• Metric data: Takes effect immediately; old data is deleted immediately and is unrecoverable. This is because metric data is large in volume and updated frequently, so the system uses an immediate cleanup strategy.

• Non-metric data (logs, traces, profiles, RUM, etc.): New data is billed under the new policy; old data is retained until the end of the original retention period. This is because non-metric data often has audit value and requires data continuity.

Shortening metric retention can reduce costs immediately, while shortening non-metric retention requires a transition period before the full cost savings are visible.

After enabling "Custom Multi-Index", why can I only change the retention policy for the "default" index? What about other indices?

Each index has its own independent retention policy. To change:

1. Go to Logs > Index Management
2. Set the retention period for each custom index individually
3. Each index is billed according to its own retention policy

If a custom index does not have a specific policy set, it inherits the policy of the default index. However, billing is calculated independently for each index, not combined.

Billing Items & Calculation Logic¶

In the Commercial Plan, logs are billed either by count or by write traffic. When is it better to switch?

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

• Single entry < 1 KB: Billing by count is usually better (1 GB ≈ 1 million entries; by count it may cost only 1 unit).
• Single entry > 10 KB (ES) or > 2 KB (SLS): Billing by traffic is better, to avoid large logs being split into multiple counted entries.

If a monitor's detection interval is set to 30 minutes, how many task invocations are calculated? 2 (30/15) or 6 (base 5 + 1 for the extra)?

The latter is correct. The billing formula is:

Total invocations = Detection type base count + ⌈(Detection interval - 15 minutes) / 15 minutes⌉

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

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

Why is the "RUM Intelligent Detection" monitor 10 times more expensive than the "Host Intelligent Detection"?

Because the billing coefficient is different:

• Host/Log/APM Intelligent Detection: 10 invocations/execution
• RUM Intelligent Detection: 100 invocations/execution

This is because RUM data is usually larger in volume and more computationally intensive. If your budget is limited, we recommend using Host Intelligent Detection first, or replacing Intelligent Detection with custom monitor rules.

Trace data is sometimes billed by trace count, sometimes by span count. How can I predict my bill?

The system automatically selects the more favorable method:

• If the number of traces ≥ 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 APM. If the average number of spans per trace is > 10, billing is likely by span; if < 10, it's by trace. You can control the number of traces by adjusting the sampling strategy, which affects the billing method.

The escalation policy notification charges 100 task invocations per trigger. Is this per notification sent?

Yes, each time an escalation policy is triggered and a notification is sent, 100 task invocations are recorded.

In the Commercial Plan, why do events and self-built synthetic test data use the log default index retention policy by default?

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

• Event data (from monitors, SLOs, intelligent inspections) is stored in the default index
• Self-built synthetic test data reported via DataKit is also stored in the default index

Therefore, their retention periods and billing unit prices inherit the configuration of the default index. If you need to adjust them separately, there is currently no way to set independent retention policies for events or self-built synthetic tests. The only way is to indirectly affect them by adjusting the default index retention period.

Exception: Although synthetic test data for TrueWatch nodes is also stored in the default index, the synthetic test execution itself is billed separately based on the number of tests, which is a different dimension from storage billing.

Data Splitting & Compression Billing¶

The splitting thresholds for large logs differ between ES and SLS storage. How do I calculate my actual count?

It depends on your storage type:

ES Storage:

• Single entry ≤ 10 KB: counts as 1
• Single entry > 10 KB: billed count = ⌈actual size / 10 KB⌉

Example: 15 KB log counts as 2, 25 KB counts as 3

SLS Storage:

• Single entry ≤ 2 KB: counts as 1
• Single entry > 2 KB: billed count = ⌈actual size / 2 KB⌉

Example: 3 KB log counts as 2, 5 KB counts as 3

A Session Replay session lasts 5 hours and is split into 2 billing units. Are these units billed continuously or based on actual active time?

Billing is based on whole units, regardless of time distribution:

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

These 2 units are charged in a single day's bill, not billed by the hour. Even if the session has 1 hour of inactivity, as long as the time_spent field shows a total duration of 5 hours, it is billed as 2 units.

If a Profile file exceeds 300 KB and is split, is it stored as separate records or only split for billing?

Only split for billing; storage remains as the original file. The system splits large Profile files into multiple records for indexing and billing (1 record per 300 KB), but at the storage layer, it is still associated as a single Profile collection. This is done to avoid performance issues caused by overly large single records, while ensuring billing is proportional to storage resource consumption.

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

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

• If the day's PV is 500, then 500/100=5, take the larger value 500, bill at 500
• If the day's PV is 50, then 50/100=0.5, take the larger value 50, still bill at 50 (not 0.5 or 1)

Only when PV > 100 does "PV/100" become greater than 1, and the system takes the PV value itself. This rule is mainly to avoid precision issues for extremely small traffic. It has no practical impact on normal business traffic (>100 PV/day).

In Sensitive Data Scanning, if multiple fields in the same log are masked, why is it charged multiple times?

Because billing is based on field-level scanning traffic:

• Each field requiring masking is calculated separately based on its raw traffic
• Even if these fields belong to the same log, they are billed independently

Example: A 1 KB log contains 3 sensitive fields. Scanning billing is calculated based on the total raw traffic of the 3 fields (which may be > 1 KB, depending on the field content size), not on the single log's 1 KB.

Version Switching & Data Migration¶

After upgrading from the Free Plan to the Commercial Plan, why can't I see the data from the Free Plan period?

Free Plan data is stored in a separate instance. After the upgrade:

• DataKit configuration: Automatically points to the Commercial Plan workspace; data continues to be reported
• Historical data: Remains in the Free Plan environment and is typically automatically cleaned up after 7 days. It cannot be viewed in the Commercial Plan

Historical data from the Free Plan cannot be migrated to the Commercial Plan. If you need to keep it, back it up via the data export function before upgrading.