Frequently Asked Questions¶

Version Selection and Billing Methods¶

Can SESSION REPLAY have its storage duration set individually to 3 or 7 days, like LOG?

This depends on your plan:

• Commercial Plan: Not supported. The SESSION REPLAY data storage policy is bound to RUM and uses RUM's unified storage policy (3 days/7 days/14 days). It cannot be adjusted individually.
• Deployment Plan: Supports configuring the SESSION REPLAY storage policy separately in the management backend.

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

TrueWatch has two billing center systems:

Currency choice affects invoice type and payment methods and must be determined when registering a workspace. If the business spans multiple regions, it is recommended to create separate workspaces in different regions, each using the local currency for settlement.

I have been using CNY for settlement for some time. Can I switch to USD settlement?

Direct self-service switching is not possible. Due to involvement with different billing center systems (China Region vs. Global Region) and account migration, the following is required:

1. Contact your account manager to submit a currency switch application.
2. Historical bills for the original workspace will remain in CNY settlement.
3. New charges generated after the switch will be settled in USD.

It is recommended to settle any outstanding CNY account balance before switching and assess the impact of exchange rate fluctuations on the budget.

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

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

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

• Enterprise Plan: Billed based on compressed write traffic + total storage volume, independent of storage duration. Suitable for scenarios with extremely large LOG volume but low query frequency, requiring long-term archiving. Even for 360-day storage, the unit price does not increase in tiers due to duration, but you pay continuously for the total storage volume.

If your data has a high compression ratio (e.g., text LOG can be compressed to 20%) and the storage cycle is 30 days, it is recommended to contact your account manager to evaluate the Enterprise Plan solution.

Data Storage Policy Changes¶

I shortened the LOG storage duration from 14 days to 3 days. Why hasn't the bill decreased immediately?

This is due to the rolling billing mechanism. For non-Metrics data (LOG, Trace, etc.) after a policy change:

1. Historical data: Continues to be retained until the original storage duration (14 days) is reached, and is billed at the higher original policy rate.
2. New data: Immediately billed at the lower new policy rate.

Therefore, the cost reduction will have a 14-day transition period. If immediate cost reduction is needed, historical data must be manually deleted (but this will result in data loss).

After a Metrics data storage policy change, old data is deleted immediately, and costs drop immediately, but the data is unrecoverable.

If I modify the storage 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.

Example scenario:

• 09:00: Changed LOG from 14 days to 7 days → Takes effect immediately, billing starts at the 7-day rate for that day.
• 15:00: Changed LOG from 7 days to 3 days → Takes effect at 00:00 the next day, today is still billed at the 7-day rate.

It is recommended not to make multiple adjustments within a day to avoid confusing billing records.

After a data storage policy change, why is the handling different for Metrics data and non-Metrics data?

• Metrics data: The change takes effect immediately. Old data is deleted immediately and cannot be recovered. This is because Metrics data is voluminous and updated frequently, and the system adopts an immediate cleanup strategy.

• Non-Metrics data (LOG, Trace, Profile, RUM, etc.): After the change, new data is billed according to the new policy, while old data is retained until the end of the original storage cycle. This is because non-Metrics data often has audit value, requiring data continuity.

Shortening the Metrics storage duration can immediately reduce costs, but shortening non-Metrics storage duration requires waiting for the transition period to see the full cost reduction effect.

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

Each index is independently bound to a storage policy. Steps to change:

1. Go to LOG > 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 does not have a policy set separately, it inherits the policy of the default index by default. However, billing is calculated independently for each index and is not merged.

Billing Items and Calculation Logic¶

In the Commercial Plan, when is it more advantageous to switch between LOG billing by count vs. by write traffic?

The key is the average size per LOG entry:

• Single entry < 1KB: Billing by count is usually better (1GB ≈ 1 million entries, billing by count might only cost 1 unit)
• Single entry > 10KB (ES) or > 2KB (SLS): Billing by traffic is better, avoiding large LOG entries being split and billed as multiple entries

If the monitor detection interval is set to 30 minutes, are Triggers calculated as 2 times (30/15) or 6 times (base 5 times + 1 time for exceeding)?

The latter is correct. The billing formula is:

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

For "Anomaly Detection" (base 5 times), with a 30-minute interval:

• Base: 5 times
• Exceeding part: (30-15)/15 = 1, rounded up to 1 time
• Total: 6 times

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

Because the billing coefficients are different:

• Host/LOG/APM Intelligent Detection: 10 times/execution
• RUM Intelligent Detection: 100 times/execution

This is because RUM data volume is typically larger and computational complexity is higher. If the budget is limited, it is recommended to prioritize using Host Intelligent Detection, or replace Intelligent Detection with custom detection rules via monitors.

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

The system automatically selects the more advantageous method:

• If Trace count ≥ Span count/10, bill by Trace (per million Traces)
• Otherwise, bill by Span (per ten million Spans)

You can check the service overview in APM. If the average number of Spans per Trace is > 10, it will likely be billed by Span; if < 10, it will likely be billed by Trace. You can control the Trace count by adjusting the sampling strategy, thereby influencing the billing method.

The escalation strategy notification deducts 100 Triggers each time it is triggered. Is it deducted every time a notification is sent?

Yes, each time an escalation strategy is hit, 100 Triggers are recorded when sending the notification.

In the Commercial Plan, why do Incident and Self-built Nodes data use the storage policy of the LOG default index by default?

Because these two types of data are physically stored in the LOG's default index:

• Incident data (generated by monitors, SLO, Intelligent Inspection) is stored in the default index.
• Self-built Nodes data reported via DataKit is also stored in the default index.

Therefore, their storage duration and billing unit price inherit the configuration of the default index. If separate adjustment is needed, currently it is not possible to directly set independent storage policies for Incident or Self-built Nodes; it can only be indirectly affected by adjusting the duration of the default index.

Exception: TrueWatch node TESTING data, although also stored in the default index, the TESTING execution itself is billed separately per TESTING count, which is a different dimension from storage billing.

Data Splitting and Compression Billing¶

The splitting thresholds for oversized LOG entries are different in ES and SLS storage. How do I calculate my actual entry count?

Calculate separately based on your storage type:

ES Storage:

• Single entry ≤ 10 KB: Counts as 1 entry
• Single entry > 10 KB: Billed entries = ⌈Actual size / 10 KB⌉

Example: A 15 KB LOG counts as 2 entries, 25 KB counts as 3 entries

SLS Storage:

• Single entry ≤ 2 KB: Counts as 1 entry
• Single entry > 2 KB: Billed entries = ⌈Actual size / 2 KB⌉

Example: A 3 KB LOG counts as 2 entries, 5 KB counts as 3 entries

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

Billed based on the rounded-up integer multiple, independent of time distribution:

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

These 2 units are counted in the daily bill at once, not billed in hourly segments. Even if the Session is inactive for 1 hour in the middle, 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 300KB and is split, is it stored as split entries, or is it only billed as split?

Only billed as split; storage remains as the original file. The system splits large Profile files into multiple records for indexing and billing (1 entry per 300KB), but at the storage level, they are still associated as one Profile collection. This is done to avoid oversized single records affecting query performance while ensuring billing is proportional to storage resource consumption.

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

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

• If the daily PV count is 500, then 500/100=5, take the larger value 500, bill for 500.
• If the daily PV count is 50, then 50/100=0.5, take the larger value 50, still bill for 50 (not 0.5 or 1).

Only when the PV count > 100 will "PV/100" be greater than 1, and then the PV count itself is taken. This rule mainly avoids calculation precision issues for extremely low traffic and has no practical impact on normal business traffic (>100 PV/day).

In sensitive data scanning, if multiple fields of the same LOG entry are masked, why does it generate multiple charges?

Because billing is based on field-level scanning traffic:

• Each field requiring masking calculates its original traffic separately.
• Even if these fields belong to the same LOG entry, they are billed separately.

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

Version Switching and Data Flow¶

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

Free Plan data is stored in an independent instance. After upgrading:

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

Historical data from the Free Plan cannot be migrated to the Commercial Plan. If retention is needed, it must be backed up via data export before upgrading.