--- title: Deprecation of TCO overrides description: TCO overrides are deprecated and become standard log policies. Migrate overrides through the UI, the API, Terraform, or the Kubernetes operator. url: https://coralogix.com/docs/user-guides/latest-updates/deprecations/tco-overrides/ product: dataengine feature: TCO Optimizer feature_id: tco-optimizer feature_identifier: dataengine/tco-optimizer last_updated: '2026-11-02' --- # Deprecation of TCO overrides **Published:** October 5, 2025 **Effective:** November 30, 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](https://coralogix.com/docs/developer-portal/apis/tco-controls/tco-optimizer-http-api.md) 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](#infrastructure-as-code-users-terraform-and-the-kubernetes-operator) 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](https://coralogix.com/docs/developer-portal/apis/tco-controls/tco-optimizer-http-api.md#tco-override) 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/` * **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/` * **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](#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](#infrastructure-as-code-users-terraform-and-the-kubernetes-operator) 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](https://coralogix.com/docs/user-guides/account-management/tco-optimizer.md). 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](#infrastructure-as-code-users-terraform-and-the-kubernetes-operator). ## 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.