Container Apps _CL log table migration blocked by locked _timestamp_d column with invalid name

Question

Container Apps _CL log table migration blocked by locked _timestamp_d column with invalid name

Taimoor Khan 20

I'm trying to migrate our Container Apps diagnostic log tables (ContainerAppConsoleLogs_CL and ContainerAppSystemLogs_CL) from classic custom tables to DCR-based tables, ahead of the HTTP Data Collector API retirement (14 Sept 2026).

When calling the official migrate endpoint: POST /subscriptions/{sub}/resourceGroups/{rg}/providers/Microsoft.OperationalInsights/workspaces/{workspace}/tables/ContainerAppConsoleLogs_CL/migrate?api-version=2025-07-01 I get: "User provided schema is invalid, due to - HttpClient: Response status code does not indicate success - 400 (Bad Request), due to reason - [Table validation failed with following 1 errors: MSG 1008: Column name _timestamp_d contains invalid characters]"

The _timestamp_d column is auto-generated by Container Apps itself (not something I added), and per Microsoft's own naming rules, column names must start with a letter, a leading underscore isn't valid. I also tried via the Portal's Schema Editor ("Migrate to manual schema management" button), same result, and the pencil/edit icon next to _timestamp_d in the schema editor is disabled, so there's no way to rename or remove the offending column myself.

Since Container Apps controls this table's schema internally, this seems to be a platform-side blocker that only the product team can fix. Is there a known workaround, or is a fix planned before the Data Collector API retirement date?

Workspace table type: Custom table (classic)

Affected tables: ContainerAppConsoleLogs_CL, ContainerAppSystemLogs_CL

Environment: Azure Container Apps, Log Analytics workspace

0 comments

Answer accepted by question author

Gursimran Singh 570 Microsoft External Staff Moderator

Hi Taimoor,

Thank you for the detailed report and for sharing the exact error + affected tables.

What’s happening

ContainerAppConsoleLogs_CL and ContainerAppSystemLogs_CL are classic custom tables created by Azure Container Apps.

These tables contain an auto-generated column named _timestamp_d.

When you try to migrate the table to DCR-based (manual schema) management, the platform validates the schema against the current custom table rules.

Those rules require column names to start with a letter. A leading underscore is not allowed, so the migration fails with:

Column name _timestamp_d contains invalid characters

Because the column is owned/locked by the Container Apps service, customers cannot rename or remove it (the edit control is disabled in the schema editor).

Current status

This is a known class of issue affecting service-generated classic _CL tables that contain columns with leading underscores (or other characters that no longer meet the stricter DCR schema rules).

Recommended actions right now

Do not rely on the in-place migrate operation for these two tables until a fix is available.
Workaround options:
- Continue using the existing classic tables for querying (ingestion will keep working until the HTTP Data Collector API retirement on 14 September 2026).
- Create new DCR-based custom tables and route future logs there (via diagnostic settings / transformation if needed).
- Alternatively, change the Container Apps environment log destination to Azure Storage or Event Hub if that meets your requirements.

We understand the timeline pressure caused by the Data Collector API retirement and are treating this as a priority.

If the above steps did not help resolve your issue, please feel free to share the details in a private message so we can proceed with further troubleshooting over a Teams call. I am happy to connect with you on Teams to investigate and resolve the issue.

Please "upvote" if the information helped you. This will help us and others in the community as well.

Taimoor Khan 20 Reputation points

2026-08-10T10:38:31.2233333+00:00

Hi Gursimran,

Thank you so much for the detailed explanation and for escalating this on your end, really appreciate it.

Since ingestion isn't currently affected and we don't have an urgent need to force this migration right now, we'll hold off on making any changes for the time being and continue using the existing classic tables as is.

I'll keep an eye on this thread for updates on the fix. If there's any progress or timeline you can share down the line, that would be great. And thank you for the offer of a Teams call, I'll reach out if we hit a blocker or need to revisit this sooner.

Appreciate your help on this!

1 additional answer

Your answer

Taimoor Khan 20 Reputation points

2026-08-10T10:38:31.2233333+00:00

Hi Gursimran,

Thank you so much for the detailed explanation and for escalating this on your end, really appreciate it.

Since ingestion isn't currently affected and we don't have an urgent need to force this migration right now, we'll hold off on making any changes for the time being and continue using the existing classic tables as is.

I'll keep an eye on this thread for updates on the fix. If there's any progress or timeline you can share down the line, that would be great. And thank you for the offer of a Teams call, I'll reach out if we hit a blocker or need to revisit this sooner.

Appreciate your help on this!

Answer 1

Solution (Ghost Mode)

No customer-side workaround currently available.

Do not attempt schema edits; _timestamp_d is system-generated and locked by Azure Container Apps.

Open a Microsoft Support ticket and request escalation to the Azure Monitor / Container Apps product team with the migration error and affected tables. [learn.microsoft.com]

If possible, configure new logging to use the modern Azure Monitor Container Apps tables (ContainerAppConsoleLogs, ContainerAppSystemLogs) instead of the legacy _CL tables. [learn.microsoft.com], [learn.microsoft.com]

Wait for a service-side fix to the migration validator, as the failure is caused by a Microsoft-managed column (_timestamp_d) being rejected during migration. [learn.microsoft.com]