Investigating Potential Azure App Service Platform Events Correlating with Duplicate Correlation IDs

Prashanth Talari 0 Reputation points
2026-09-21T08:05:48.11+00:00

Investigating Potential Azure App Service Platform Events Correlating with Duplicate Correlation IDs

We are investigating an issue reported within a production Azure-hosted application and have identified a pattern that appears to have started on 04 September 2026.

Observed Behaviour

Our analysis shows a significant number of cases where the same InitialCorrelationId is associated with multiple distinct messages, resulting in different Transaction IDs and Sender Unique References. This behaviour was first observed on 04 September 2026 and continues thereafter.

Additional Findings

InitialCorrelationId and TransactionId are generated by the same application code path. As a result, both identifiers are exhibiting similar duplication patterns.

We are not aware of any application, configuration, or infrastructure changes made from our side around the time the issue began.

Duplicate values have been identified within our downstream data platform, where:

The same InitialCorrelationId is associated with multiple distinct message references.

The same TransactionId is also observed against multiple distinct messages.

Both identifiers originate from the same application logic and therefore appear to be affected in a consistent manner.

Timeline of the Issue

The following table shows the number of correlation IDs associated with multiple message references:

Ingestion Date    Count04-Sep-2026    12,286

05-Sep-2026    143,011

06-Sep-2026    142,142

07-Sep-2026    129,711

08-Sep-2026    112,240

09-Sep-2026    122,195

10-Sep-2026    58,443

15-Sep-2026    3,798

The behaviour begins on 04 September 2026, with a substantial increase starting on 05 September 2026.

Query:

  • We would like to understand whether any Azure platform activity could have occurred around 04–05 September 2026 that might explain application instance restarts or recycling behaviour.
  • Specifically, are there any known Azure platform events or maintenance activities that could have resulted in App Service instances being restarted, recycled, or replaced during this period?

Examples include:

App Service instance restarts or recycles

App Service Plan host or instance changes

Platform maintenance or infrastructure updates

Operating system, runtime, or platform updates

Scale-out or scale-in events

Instance replacement activities

Host migrations

Underlying infrastructure changes

Any other Azure platform operation that could trigger App Service restarts

Environment

Azure App Service (Production workload)

UK region

Issue first observed: 04 September 2026

The application is hosted on a dedicated App Service Plan

Investigation focus: determining whether Azure platform-level events could correlate with the start of the observed identifier duplication pattern

Request

  1. Has anyone experienced similar behaviour following App Service instance restarts, platform maintenance, host migrations, or infrastructure updates?
  2. Additionally, is there a way to determine whether any Azure platform maintenance, host replacement, or underlying infrastructure activity occurred for an App Service Plan during a specific timeframe (04–05 September 2026)?

Any guidance on logs, diagnostic data, or platform telemetry that could help validate or rule out Azure-side events would be greatly appreciated.

Thank you for your assistance.

Azure App Service
Azure App Service

Azure App Service is a service used to create and deploy scalable, mission-critical web apps.

0 comments

1 answer

Sort by: Most helpful
Most helpful Newest Oldest
  1. Divyesh Govaerdhanan 11,890 Reputation points MVP Volunteer Moderator
    2026-09-21T19:58:14.2966667+00:00

    Hi Prashanth Talari,

    Welcome to Microsoft Q&A,

    You can check for platform events on your plan, but a restart or instance move on its own would not make the same InitialCorrelationId appear on different messages. So check both the platform side and how the IDs are generated.

    Checking for platform events (04 to 05 Sept)

    1. Service Health: Open Service Health and check Planned maintenance and Health history. Filter by your UK region and the date range. Health history keeps 90 days in the portal. On an event's Impacted Resources tab, More info shows the state and timestamps for your resources.
    2. Resource Health: Open Resource Health on the app or plan. Its health history covers the last 30 days.
    3. App Service diagnostics: Go to Diagnose and solve problems, then run Web App Restarted. Also check Worker Process Events, Instance Allocation Events, and Platform Observations (available in the Web App Slow detector) for your date range. The docs say this experience works best for the last 24 hours, so older ranges may be thin.
    4. Activity log: Use it for actions you or your pipelines took (scale, config, deploy). If autoscale is on, check its Run history. Platform-initiated restarts often don't appear in the Activity log, so an empty log doesn't rule them out.
    5. Runtime patches: Patch updates to .NET, PHP, Java SDK and Tomcat are applied automatically by overwriting the existing install. OS patching is monthly. A runtime patch could change behavior with no change on your side. Compare the runtime version in Kudu with what you had before. On Linux, Stack settings > Platform Release Channel controls how quickly patches arrive.

    Checking the app side

    Log the instance ID (WEBSITE_INSTANCE_ID) and process start time next to each generated ID, then compare the first duplicates against restart or scale times. Duplicates usually come from state that resets on start, such as a clock-seeded random generator, an in-memory counter, or a cached ID. A restart, scale-out or runtime patch can expose that. If Service Health shows nothing for your resources and you need Microsoft to confirm backend telemetry, open a support request. Technical requests need a paid support plan.

    If this helped, please click Accept Answer and upvote.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.