Open in ChatGPTOpen in Claude

Deprecation of TCO overrides

Published: October 5, 2025

Effective: March 31, 2026

Deprecation notice

To simplify cost controls and eliminate duplicate concepts, Coralogix is deprecating the TCO overrides feature, which will no longer be accessible in the TCO Optimizer API or the TCO Optimizer UI for logs. During the hybrid phase, existing override endpoints remain functional, and your override rules continue to apply.

After the cutoff date, overrides will no longer be available. All existing override rules will appear as standard TCO policies at the top of the Log policies table and will execute before more general policies, preserving current behavior. If you manage TCO log policies with Terraform or the Kubernetes operator, this holds only if you follow the steps in Infrastructure as code users first.

Action is required for some users (see audience-specific guidance below).

Why this is happening

TCO now uses a single, consistent mechanism - policies - to route logs by business value across tiers (High, Medium, Low, Blocked) and to apply archive retention. Maintaining a parallel “override” concept created confusion, doubled the surface area for automation, and risked drift between UI, API, and Terraform.

What’s changing

• The TCO Optimizer Override API will be deprecated. Calls continue to work during the hybrid phase and then will return errors after the cutoff date.
• The Overrides table in the UI is being retired. During the hybrid phase it remains visible; after the cutoff, it is removed. Each existing override will be represented as a standard TCO policy with the same matching conditions (application, subsystem, severity), priority, and archive retention. Converted items appear at the top of Log policies and run first.

What you need to do

Choose the path that matches how you manage TCO today.

Exclusive UI users

During the hybrid phase

Migrate overrides in bulk from the Overrides table:

1. Select one or more override rows. Use the header checkbox to select every row at once.
2. Select Convert to policy to migrate the selected overrides into log policies, or Delete to remove them.
3. Confirm the action in the dialog box that appears.

Each converted override is removed from the Overrides table and recreated as a policy with the same conditions, priority, and archive retention. The new policies appear at the top of Log policies and run before broader rules. Conversion cannot be reversed.

The delete dialog shows how many rows are being removed and warns that deletion is permanent.

If a bulk action succeeds for some rows but fails for others (for example, when a quota or fair-use limit is reached) a results dialog lists the rules that failed and why. Re-run the action on the failed rows once the limit is resolved.

If you lack permission to manage TCO policies, the Convert to policy and Delete buttons stay disabled and a tooltip explains the missing access. All bulk conversions and deletions are recorded in the audit log.

Note: If you take no action, at the end of the hybrid phase, all existing override rules will appear as standard TCO policies at the top of the Log policies table and will execute before more general policies, preserving the current behavior.

When to delete vs convert overrides

• If the override priority equals the fallback priority (the priority that would apply without the override), you can safely delete the override.
• Otherwise, convert it to preserve behavior.

After the cutoff

• The Overrides table is removed. Any remaining overrides will appear automatically as policies at the top of Log policies.

API users (using the TCO Overrides API)

What’s affected

Any use of the following endpoints will stop functioning after the cutoff date:

• GET /overrides: https://api.eu2.coralogix.com.coralogix.com/api/v1/external/tco/overrides
• GET /overrides/{id}: https://api.eu2.coralogix.com.coralogix.com/api/v1/external/tco/overrides/<id>
• POST /overrides: https://api.eu2.coralogix.com.coralogix.com/api/v1/external/tco/overrides
• POST /overrides/bulk:https://api.eu2.coralogix.com.coralogix.com/api/v1/external/tco/overrides/bulk
• PUT /overrides/bulk: https://api.eu2.coralogix.com.coralogix.com/api/v1/external/tco/overrides/bulk
• DELETE /overrides/{id}: https://api.eu2.coralogix.com.coralogix.com/api/v1/external/tco/overrides/<id>
• DELETE /overrides/bulk: https://api.eu2.coralogix.com.coralogix.com/api/v1/external/tco/overrides/bulk

After the cutoff, calls to Overrides endpoints fail; policies continue to work.

Infrastructure as code users (Terraform and the Kubernetes operator)

Action is required. This section applies to you if you manage your TCO log policies with the Coralogix Terraform provider or with the Coralogix Kubernetes operator.

Your next apply can erase the migrated policies

Terraform and the Kubernetes operator both replace your entire log policy list with whatever your configuration declares. Once your overrides become log policies, whether you convert them yourself or the cutoff sweeps up what is left, the first terraform apply or operator reconcile that runs against your existing configuration deletes those new policies, and the override data is lost. Logs that an override used to route then fall back to whichever broader policy matches them next.

The operator reconciles on its own schedule, so this can happen without anyone running a command.

Step 1. Pause your automation. Stop the scheduled terraform apply and pause the CI job that runs it. If you use the Kubernetes operator, scale the operator deployment to 0 and pause its GitOps sync. Running terraform plan is safe.

Do not delete your TCOLogsPolicies object. Deleting it removes every log policy in your account, not only the converted ones.

Step 2. Convert your overrides. In the TCO Optimizer, open the Overrides table, select the rows you want to migrate, and select Convert to policy. Each override becomes a standard log policy with the same matching conditions, priority, and archive retention, placed at the top of the Log policies table so it continues to run before your broader policies. See Exclusive UI users for the full bulk flow.

Step 3. Export the new configuration. In the TCO Optimizer, go to Log policies, select View as code, and choose Terraform or K8s. The export covers your existing policies together with the newly converted ones.

Step 4. Update your code. Bring the exported policy definitions into your configuration, replacing the policies you declare today. Terraform users update the coralogix_tco_policies_logs resource, keeping the same resource name so the resource is updated rather than replaced. Kubernetes operator users update the spec of the existing TCOLogsPolicies object.

Treat the export as the authoritative list of policies rather than as a drop-in file. If your configuration uses variables, modules, or policy fields that the export does not reproduce, merge the new policies into your existing structure instead of overwriting it wholesale.

Step 5. Verify before you re-enable anything. Terraform users run terraform plan and confirm all of the following:

• The plan reports no changes to your TCO resources. If it proposes deleting or replacing policies, your configuration does not yet match what is live. Correct the configuration and plan again.
• The number of policies and their order match what the Log policies table shows in the UI.
• Every converted policy carries the archive retention you expect. A converted policy that lands on the default retention tag instead of the retention it inherited is the most likely error, and it is easiest to catch now.

Kubernetes operator users have no dry-run equivalent. Instead, compare the spec of your TCOLogsPolicies object against the exported configuration line by line, and confirm the Log policies table in the UI matches it, before you scale the operator back up.

Step 6. Turn your automation back on. Re-enable the scheduled apply, or scale the operator back up and resume its GitOps sync.

If you skip these steps

Your next apply or reconcile restores your old configuration, the converted policies are deleted, and the routing and archive retention that your overrides provided are lost. Recovering them means recreating each policy by hand.

FAQs

Will performance or features change?

No. The conversion preserves behavior. Features by tier remain the same (for example, High supports Lightning Queries, Medium supports monitoring and alerts, Low supports archival and retrieval).

If you manage TCO log policies with Terraform or the Kubernetes operator, this holds only if you follow the steps in Infrastructure as code users first.

What happens if my override conflicts with an existing policy?

Order resolves conflicts. Converted overrides appear as policies at the top of Log policies and run first.

What if I do nothing?

At cutoff, overrides are converted to top-ordered policies automatically in the UI. Find out more here.

If you manage your TCO policies with Terraform or the Kubernetes operator, doing nothing is not safe. Your next apply deletes the converted policies. See Infrastructure as code users.

Need help?

Reach out via in-app chat or contact your Technical Account Manager. We’re happy to review your current overrides and propose equivalent policies and order.