Clock skew between Azure Container Apps in the same Container App Environment

Hello @David Barker

A persistent 2+ second clock difference between Container Apps replicas isn't something I would try to correct by running your own NTP service inside the containers.

Azure Container Apps is a managed PaaS service, so the Azure platform manages the underlying host OS and time synchronization rather than your container. Customers don't have the same control over host time synchronization that they would with an Azure VM.

Your observations are particularly interesting:

Previously: < 1 second difference

Since ~20 August: 2+ seconds

Affected: two Container App environments

Replica restart: immediately resolves the skew

The fact that restarting the affected replicas corrects the clock strongly suggests that this isn't simply an application timezone or formatting issue.

Azure's underlying hosts are synchronized against Microsoft-managed time infrastructure. Azure documentation for its compute infrastructure explains that Azure hosts synchronize against internal Microsoft time servers backed by Microsoft-owned Stratum 1 devices.

First, verify whether your Container Apps environments use custom VNet networking, NSGs, Azure Firewall, or another outbound filtering mechanism.

For Azure Container Apps network configurations where outbound traffic is controlled, Microsoft documents UDP port 123 as required for NTP:

Protocol: UDP

*Destination: **

Port: 123

Purpose: Network Time Protocol (NTP)

If you recently changed an NSG, firewall, UDR, or egress policy, verify that UDP/123 hasn't been blocked.

However, if you haven't made any networking changes, collect evidence before restarting the replicas again.

For example, from both Container Apps at approximately the same instant, log: UTC timestamp, Container App name, Revision, Replica name, Environment, and Region.

Container Apps exposes environment variables such as CONTAINER_APP_NAME, CONTAINER_APP_REVISION, and CONTAINER_APP_REPLICA_NAME, which can help identify whether the skew consistently follows particular replicas.

I'd also test both applications against the same external authoritative time source rather than comparing App A's timestamp directly with App B's timestamp. That helps distinguish actual clock drift from request latency between the applications.

If you can reproduce something like:

Replica A offset: +0.1 sec

Replica B offset: +2.4 sec

Restart Replica B

Replica A offset: +0.1 sec

Replica B offset: +0.1 sec

that's much stronger evidence of host/replica clock drift.

I would also check whether Azure platform maintenance occurred around the time this started. Container Apps can receive platform updates, including critical updates outside configured maintenance windows. Microsoft provides maintenance history for environments with configured maintenance windows.

As for whether Microsoft changed something around August 20, I can't find a public Microsoft advisory or documented Container Apps change that specifically identifies clock synchronization changes during that period. So I wouldn't claim that this is a known service regression without confirmation from Microsoft.

Given that:

• this reportedly worked correctly for six months,
• it recently appeared in two environments,
• the skew grows beyond two seconds, and
• restarting replicas corrects it,

I would open an Azure Container Apps support case if UDP/123 and your network configuration check out.

Provide Microsoft with the environment names, Azure regions, affected revision/replica names, UTC timestamps showing the measured offsets, approximately when the drift begins, and timestamps showing that a replica restart immediately corrects it. That should give the Container Apps engineering team enough information to correlate the affected replicas with the underlying platform hosts.

One application-design consideration as well: if the application requires clocks across distributed services to remain within one second for correctness, I wouldn't use wall-clock synchronization between replicas as the sole coordination mechanism. Even with synchronized infrastructure, distributed applications should generally tolerate some clock uncertainty and use sequence numbers, database-generated timestamps, monotonic clocks, or another authoritative source where strict ordering matters.

Microsoft references:

Azure Container Apps networking/firewall requirements

Azure Container Apps planned maintenance

Azure time synchronization architecture

If you can share the regions of the two affected Container App environments and whether they're VNet-integrated, that would help determine whether a common infrastructure/networking factor is involved.

Help make this community better for everyone: if this answer resolved your issue, please accept it or leave an upvote. If not, share more details in a comment so we can continue the discussion and find the right solution.

Hi David,

This is known current issue affecting Azure Container Apps.

Below is latest update from Service issue SR9B-K5G:

Impact Statement:

Starting at 00:00 UTC on 17 August 2026, customers using Azure Container Apps on Consumption workload profiles across multiple regions may experience application issues caused by system clock drift on the underlying infrastructure. Workloads that rely on accurate timekeeping — such as token validation (JWT nbf/exp), TLS certificate checks, scheduled operations, or timestamp-dependent logic — may encounter intermittent failures that worsen over time as the clock drifts further.

Dedicated workload profiles are not affected.

Workaround: Two mitigations are available while the fix is being deployed:

1. Restart the affected application — this resets the system clock to the correct time, though drift may recur over time.
2. Move the application to a Dedicated workload profile — Dedicated profiles use a different infrastructure that is not affected by this issue. This is the more durable workaround.

Applications using time-sensitive authentication tokens, certificates, or timestamp validation should be monitored for errors consistent with clock skew (e.g., "token not yet valid", certificate validity errors, or authorization failures).

Current Status: We have identified that a recent infrastructure image update for Consumption workload profiles removed a required time synchronization component (NTP service), causing system clocks on affected infrastructure to drift. A code fix has been merged and is being incorporated into an upcoming critical hotfix infrastructure release. We are actively working to expedite deployment of this fix across all regions.

The next update will be provided on 28 August 2026, or as events warrant.

Thanks.

-TP

Hi @David Barker ,

This appears to be a known Azure Container Apps platform issue affecting Consumption workload profiles across multiple regions.

• The issue began around 17–20 August 2026 and causes clock drift of more than 2 seconds between replicas.
• Restarting an affected replica temporarily corrects the clock.
• The reported root cause is a recent infrastructure image update that removed the NTP time-synchronization component from Consumption infrastructure.
• This can cause JWT validation, TLS, authorization, and scheduled-job failures.
• Dedicated workload profiles are reportedly not affected.

Recommended action

• Short-term: Restart affected Container Apps/replicas.
• Long-term: Consider moving critical workloads to a Dedicated workload profile until the platform issue is resolved.
• Provide Azure Support with the environment/region, affected replicas, UTC timestamps, clock-offset measurements, and evidence that restarting the replica corrects the drift.

Conclusion: The issue is most likely platform-side and not caused by the customer's application, networking, or configuration.