Request-Context
The unofficial Request-Context request and response header is used by Azure Application Insights to enable distributed tracing across application components.
Usage
Azure Application Insights attaches the Request-Context header to HTTP responses from instrumented applications. The header carries an application identifier allowing the Application Insights SDK to correlate telemetry across service boundaries. When one service calls another, the SDK reads this header to establish a parent-child relationship between the two operations in the distributed trace.
The header works alongside other Azure tracing mechanisms. The X-Azure-Ref header provides an opaque request identifier from Azure Front Door, while Request-Context carries structured key-value pairs specifically for Application Insights correlation. The X-Request-Id header serves a similar purpose in non-Azure environments, providing a unique identifier for request tracking across services.
The value is a set of key-value pairs separated by commas.
The most common key is appId, which contains a
cid-v1: prefix followed by a GUID identifying the
Azure Application Insights resource. This GUID maps to a
specific Application Insights instance in Azure Monitor
and enables cross-component correlation in the
application map.
Values
appId
The appId key contains the Application Insights
component identifier in cid-v1:GUID format. The GUID
is a unique identifier for the Application Insights
resource. Multiple services sharing the same appId
belong to the same logical application, while different
appId values indicate separate components in the
distributed trace.
Example
A response from an Azure-hosted application instrumented
with Application Insights. The appId value identifies
the specific Application Insights resource handling
telemetry for this service. The cid-v1: prefix
indicates version 1 of the correlation ID format.
Request-Context: appId=cid-v1:7a2f7338-f02a-4193-92ae-74e60d548529
A different application component returns its own
Application Insights identifier. When the SDK detects
two different appId values in a call chain, the
application map in Azure Monitor draws a dependency
arrow between the two components.
Request-Context: appId=cid-v1:1a48b233-1521-4c8c-941c-79a55d14eae7
A response from a third application. Each unique GUID represents a separately instrumented service, and Application Insights uses these identifiers to reconstruct the full request flow across all participating components.
Request-Context: appId=cid-v1:ed1e046e-7efd-4409-95ee-ae23960f1445
A correlation header on borrowed time
Request-Context belongs to Microsoft Application
Insights, and the dominant value, appId=cid-v1:
followed by a GUID, names the Application Insights
resource behind the response. The header runs in both
directions: the JavaScript SDK attaches the caller's
identity to outgoing requests, the server SDK stamps
responses with its own, and differing identifiers on
the two sides of a call draw the dependency edge in
the Application Map.
The browser SDK sends the header by default, and
cross-origin calls are where deployments stumble.
The target's CORS policy needs Request-Context in
Access-Control-Allow-Headers
for the request leg, and reading the response side
needs the header exposed, producing the widely seen
"Failed to get Request-Context correlation header"
warning where either is missing.
Microsoft is retiring the mechanism in favor of Traceparent and W3C Trace Context. The classic SDKs emitting the header are deprecated, with the .NET line retiring in March 2027, and the OpenTelemetry-based replacements inject no legacy headers. Observed instances today are almost entirely .NET and IIS applications on the classic SDK, and the population shrinks toward the retirement date.
