--- title: "Contexts Interface" url: https://develop.sentry.dev/sdk/foundations/transport/event-payloads/contexts/ --- # Contexts Interface The Contexts Interface provides additional context data. Typically, this is data related to the current user and the environment. For example, the device or application version. Its canonical name is `contexts`. The `contexts` type can be used to define arbitrary contextual data on the event. It accepts an object of key/value pairs. The key is the "alias" of the context and can be freely chosen. However, as per policy, it should match the type of the context unless there are two values for a type. You can omit `type` if the key name is the type. When adding additional data to the event data model contexts are a good fit when you have all the data available at a single point in time. Contexts are not well suited to data that is collected over time as the SDK interfaces for contexts don't afford merging of data. Unknown data for the contexts is rendered as a key/value list. In the Sentry Product, certain contexts are rendered in a special way to make it more readable. More details about this can be found in the [contexts code on the Sentry UI](https://github.com/getsentry/sentry/tree/master/static/app/components/events/contexts). For more details about sending additional data with your event, see the [full documentation on Additional Data](https://docs.sentry.io/platform-redirect/?next=/enriching-events/context/). ## [Device Context](https://develop.sentry.dev/sdk/foundations/transport/event-payloads/contexts.md#device-context) Device context describes the device that caused the event. This is most appropriate for mobile applications. The `type` and default key is `"device"`. * `name` **Required**. The name of the device. This is typically a hostname. * `family` *Optional*. The family of the device. This is usually the common part of model names across generations. For instance, `iPhone` would be a reasonable family, so would be `Samsung Galaxy`. * `model` *Optional*. The model name. This, for example, can be `Samsung Galaxy S3`. * `model_id` *Optional*. An internal hardware revision to identify the device exactly. * `arch` *Optional*. The CPU architecture. * `battery_level` *Optional*. If the device has a battery, this can be a floating point value defining the battery level (in the range 0-100). * `battery_temperature` *Optional*. If the device has a battery, this can be a floating point value defining the battery temperature in Celsius. * `orientation` *Optional*. This can be a string `portrait` or `landscape` to define the orientation of a device. * `manufacturer` *Optional*. The manufacturer of the device. * `brand` *Optional*. The brand of the device. * `screen_resolution` *Optional*. The screen resolution. (e.g.: 800x600, 3040x1444). * `screen_height_pixels` *Optional*. The height of the screen. * `screen_width_pixels` *Optional*. The width of the screen. * `screen_density` *Optional*. A floating point denoting the screen density. * `screen_dpi` *Optional*. A decimal value reflecting the DPI (dots-per-inch) density. * `online` *Optional*. Whether the device was online or not. * `charging` *Optional*. Whether the device was charging or not. * `low_memory` *Optional*. Whether the device was low on memory. * `simulator` *Optional*. A flag indicating whether this device is a simulator or an actualdevice. * `memory_size` *Optional*. Total system memory available in bytes. * `free_memory` *Optional*. Free system memory in bytes. * `usable_memory` *Optional*. Memory usable for the app in bytes. * `storage_size` *Optional*. Total device storage in bytes. * `free_storage` *Optional*. Free device storage in bytes. * `external_storage_size` *Optional*. Total size of an attached external storage in bytes (for example, android SDK card). * `external_free_storage` *Optional*. Free size of an attached external storage in bytes (for example, android SDK card). * `boot_time` *Optional*. A formatted UTC timestamp when the system was booted. For example, `"2018-02-08T12:52:12Z"`. * `timezone` *Optional*. The timezone of the device. For example, `Europe/Vienna`. This field is deprecated, please use `timezone` of [culture context](https://develop.sentry.dev/sdk/foundations/transport/event-payloads/contexts.md#culture-context) instead. * `language` *Optional*. The language of the device. For example, `en`. This field is deprecated, please use `locale` of [culture context](https://develop.sentry.dev/sdk/foundations/transport/event-payloads/contexts.md#culture-context) instead. * `processor_count` *Optional*. Number of "logical processors". For example, `8`. * `cpu_description` *Optional*. CPU description. For example, `Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz`. * `processor_frequency` *Optional*. Processor frequency in MHz. Note that the actual CPU frequency might vary depending on current load and power conditions, especially on low-powered devices like phones and laptops. * `device_type` *Optional*. Kind of device the application is running on. For example, `Unknown, Handheld, Console, Desktop`. * `battery_status` *Optional*. Status of the device's battery. For example, `Unknown, Charging, Discharging, NotCharging, Full`. * `device_unique_identifier` *Optional*. Unique device identifier. This value might only be used if `sendDefaultPii` is enabled. * `supports_vibration` *Optional*. Is vibration available on the device? * `supports_accelerometer` *Optional*. Is accelerometer available on the device? * `supports_gyroscope` *Optional*. Is gyroscope available on the device? * `supports_audio` *Optional*. Is audio available on the device? * `supports_location_service` *Optional*. Is the device capable of reporting its location? ## [OS Context](https://develop.sentry.dev/sdk/foundations/transport/event-payloads/contexts.md#os-context) OS context under the default key `"os"` describes the operating system on which the crash happened/the event was created. The `type` and default key is `"os"`. However, since contexts can be set multiple times under different keys, there has historically been a lot of confusion about which OS context represents what. So here's some examples: * In events reported from a Python/ASP.NET/Rails web backend, the OS context under the default key `"os"` is the server's operating system, and is set by the SDK (if at all). Additionally, the Sentry server will attempt to parse the `User-Agent` header from the event's [Request Interface](https://develop.sentry.dev/sdk/foundations/transport/event-payloads/request.md) and create a *secondary* OS context under the non-default key `"client_os"`. * In events reported from a JS web frontend, the SDK typically reports no OS context. The server however knows by looking at the platform (`"javascript"`) that the incoming User-Agent can only come from the crashing device, and creates the User-Agent based OS context under the default key `"os"`. To summarize: * `"os"` key for the device generating the event. * `"client_os"` key for an adjacent client device's OS (that is *not* the device creating the event) if it's important. The Sentry server sets this as part of User-Agent parsing, but SDKs can set this directly too. * If in doubt, just send `"os"`. Any other keys are not searchable in the product and will not be visually pronounced using icons, so using something like `"server_os"` to clarify what you meant is probably going to backfire with regards to the overall product experience. Under the existing mental model, a hypothetical `"server_os"` key would actually mean you're reporting the operating system of an adjacent "upstream" device that the crashing device is talking to. As Kurt Tucholsky said: "The opposite of good is not evil, but good intentions" - `name` *Recommended*. The name of the operating system. It might be derived from `raw_description`. It is **required** if `raw_description` is not provided. - `version` *Optional*. The version of the operating system. - `build` *Optional*. The internal build revision of the operating system. - `kernel_version` *Optional*. An independent kernel version string. This is typically the entire output of the `uname` syscall. - `rooted` *Optional*. A flag indicating whether the OS has been jailbroken or rooted. - `theme` *Optional*. Either `light` or `dark`. Describes whether the OS runs in dark mode or not. - `raw_description` *Optional*. An unprocessed description string obtained by the operating system. For some well-known runtimes, Sentry will attempt to parse `name` and `version` from this string, if they are not explicitly given. - `distribution_name` *Optional*. A stable name for each distribution. This maps to `ID` in [`/etc/os-release`](https://www.freedesktop.org/software/systemd/man/latest/os-release.html#ID=) (examples: `ubuntu`, `rhel`, `alpine`; a full list of tested identifiers is available in the [Native SDK repository](https://github.com/getsentry/sentry-native/blob/master/tests/fixtures/os_releases/distribution_names.txt)) - `distribution_version` *Optional*. Typically identifies at least the major release version number. This maps to `VERSION_ID` in [`/etc/os-release`](https://www.freedesktop.org/software/systemd/man/latest/os-release.html#VERSION_ID=). Distributions with rolling releases only, will not provide a version. - `distribution_pretty_name` *Optional*. Typically provides the full name, full version, and release alias. This maps to `PRETTY_NAME` in [`/etc/os-release`](https://www.freedesktop.org/software/systemd/man/latest/os-release.html#PRETTY_NAME=) (examples: `Ubuntu 22.04.4 LTS`, `Raspian GNU/Linux 10 (buster)`). **Example OS Context** The OS Context for the 3 major OSs should look like this: ```json { "windows": { "type": "os", "name": "Windows", "version": "10.0.19041", "build": "662" }, "mac": { "type": "os", "name": "macOS", "version": "11.1.0", "build": "20C69", "kernel_version": "20.2.0" }, "linux": { "type": "os", "name": "Linux", "version": "6.1.82(99.168.amzn2023.x86_64)", "distribution_name": "amzn", "distribution_version": "2023", "distribution_pretty_name": "Amazon Linux 2023.4.20240401" } } } ``` ## [Runtime Context](https://develop.sentry.dev/sdk/foundations/transport/event-payloads/contexts.md#runtime-context) Runtime context describes a runtime in more detail. Typically, this context is used multiple times if multiple runtimes are involved (for instance, if you have a JavaScript application running on top of JVM). The `type` and default key is `"runtime"`. * `name` *Recommended*. The name of the runtime. It might be derived from `raw_description`. It is **required** if `raw_description` is not provided. * `version` *Optional*. The version identifier of the runtime. * `raw_description` *Optional*. An unprocessed description string obtained by the runtime. For some well-known runtimes, Sentry will attempt to parse `name` and `version` from this string, if they are not explicitly given. ## [App Context](https://develop.sentry.dev/sdk/foundations/transport/event-payloads/contexts.md#app-context) App context describes the application. As opposed to the runtime, this is the actual application that was running and carries metadata about the current session. The `type` and default key is `"app"`. * `app_start_time` *Optional*. Formatted UTC timestamp when the user started the application. * `device_app_hash` *Optional*. Application-specific device identifier. * `build_type` *Optional*. String identifying the kind of build. For example, `testflight`. * `app_identifier` *Optional*. Version-independent application identifier, often a dotted bundleID. * `app_name` *Optional*. Human readable application name, as it appears on the platform. * `app_version` *Optional*. Human readable application version, as it appears on the platform. * `app_build` *Optional*. Internal build identifier, as it appears on the platform. * `app_memory` *Optional*. Amount of memory used by the application in bytes. * `app_arch` *Optional*. The CPU architecture of the application. This may differ from the device CPU architecture. * `in_foreground` *Optional*. A flag indicating whether the app is in foreground or not. An app is in foreground when it's visible to the user. * `permissions` *Optional*. A dictionary of permissions that the application uses. Each entry in the dictionary conforms to the following structure: `: 'granted|denied|not_granted'`.If a platform doesn't provide capabilities to identify whether a permission has been `denied`, then `not_granted` can be used. * `view_names` *Optional*. A list of visible UI screens at the current point in time. * `start_type` *Optional*. The way the OS started the app. For example, `cold`, `warm`, `cold.prewarmed`, or `warm.prewarmed`. ## [Browser Context](https://develop.sentry.dev/sdk/foundations/transport/event-payloads/contexts.md#browser-context) Browser context carries information about the browser or user agent for web-related errors. This can either be the browser this event occurred in or the user agent of a web request that triggered the event. The `type` and default key is `"browser"`. * `name` **Required**. Display name of the browser application. * `version` *Optional*. Version string of the browser. ## [GPU Context](https://develop.sentry.dev/sdk/foundations/transport/event-payloads/contexts.md#gpu-context) GPU context describes the GPU of the device. * `name` **Required**. The name of the graphics device. * `version` *Optional*. The Version of the graphics device. * `id` *Optional*. The PCI identifier of the graphics device. * `vendor_id` *Optional*. The PCI vendor identifier of the graphics device. * `vendor_name` *Optional*. The vendor name as reported by the graphics device. * `memory_size` *Optional*. The total GPU memory available in Megabytes. * `api_type` *Optional*. The device low-level API type. Examples: `"Apple Metal"` or `"Direct3D11"` * `driver_version` *Optional*. The driver version of the graphics device. * `multi_threaded_rendering` *Optional*. Whether the GPU has multi-threaded rendering or not. * `npot_support` *Optional*. The Non-Power-Of-Two-Support support. * `max_texture_size` *Optional*. Largest size of a texture that is supported by the graphics hardware. For example, `16384`. * `graphics_shader_level` *Optional*. Approximate "shader capability" level of the graphics device. For example, `Shader Model 2.0, OpenGL ES 3.0, Metal / OpenGL ES 3.1, 27 (unknown)`. * `supports_draw_call_instancing` *Optional*. Is GPU draw call instancing supported? * `supports_ray_tracing` *Optional*. Is ray tracing available on the device? * `supports_compute_shaders` *Optional*. Are compute shaders available on the device? * `supports_geometry_shaders` *Optional*. Are geometry shaders available on the device? **Example GPU Context** ```json { "contexts": { "gpu": { "name": "AMD Radeon Pro 560", "vendor_name": "Apple", "memory_size": 4096, "api_type": "Metal", "multi_threaded_rendering": true, "version": "Metal", "npot_support": "Full" } } } ``` ## [State Context](https://develop.sentry.dev/sdk/foundations/transport/event-payloads/contexts.md#state-context) State context describes the state of the application (e.g.: Redux store object). The `type` and default key is `"state"`. * `state` **Required**. Object with two keys: *Optional* `type` for naming the state library (e.g.: Redux, MobX, Vuex) and **Required** `value` that holds the state object. **Example State Context** ```json { "contexts": { "state": { "state": { "type": "MobX", "value": { "flights": [], "airports": [], "showModal": false } } } } } ``` ## [Culture Context](https://develop.sentry.dev/sdk/foundations/transport/event-payloads/contexts.md#culture-context) Culture Context describes certain properties of the culture in which the software is used. The `type` and default key is `"culture"`. * `calendar` *Optional*. For example `GregorianCalendar`. Free form string. * `display_name` *Optional*. Human readable name of the culture. For example `English (United States)` * `locale` *Optional*. The name identifier, usually following the RFC 4646. For example `en-US` or `pt-BR`. * `is_24_hour_format` *Optional*. boolean, either `true` or `false`. * `timezone` *Optional*. The timezone of the locale. For example, `Europe/Vienna`. ## [Cloud Resource Context](https://develop.sentry.dev/sdk/foundations/transport/event-payloads/contexts.md#cloud-resource-context) Cloud Resource Context describes certain properties of cloud provider the software is running. The data in the context abides to the [Cloud](https://opentelemetry.io/docs/reference/specification/resource/semantic_conventions/cloud/) and [Host](https://opentelemetry.io/docs/reference/specification/resource/semantic_conventions/host/) semantic conventions of OpenTelemenetry. The `type` and default key is `"cloud_resource"`. * `cloud.provider` *Optional*. Name of the cloud provider. - List of well-known values. If one of them applies, then the respective value MUST be used, otherwise a custom value MAY be used: * `alibaba_cloud` - Alibaba Cloud * `aws` - Amazon Web Services * `azure` - Microsoft Azure * `gcp` - Google Cloud Platform * `ibm_cloud` - IBM Cloud * `tencent_cloud` - Tencent Cloud - Example: `aws` * `cloud.account.id` *Optional*. The cloud account ID the resource is assigned to. - Example: `111111111111` * `cloud.region` *Optional*. The geographical region the resource is running. - Example: `us-central1` or `us-east-1` * `cloud.availability_zone` *Optional*. Cloud regions often have multiple, isolated locations known as zones to increase availability. Availability zone represents the zone where the resource is running. - Example: `us-east-1c` * `cloud.platform` *Optional*. The cloud platform in use. The prefix of the service SHOULD match the one specified in `cloud.provider`. - Example: `aws_ecs` * `host.id` *Optional*. Unique host ID. - Example: `3635354529892309001` * `host.type` *Optional*. Machine type of host. - Example: `t4g.medium` **Example Cloud Resource Context** The following example illustrates the contexts part of the [event payload](https://develop.sentry.dev/sdk/foundations/transport/event-payloads.md) and omits other attributes for simplicity. ```json { "contexts": { "cloud_resource": { "cloud.provider": "aws", "cloud.platform": "aws_ec2", "cloud.account.id": "499517922981", "cloud.region": "us-east-1", "cloud.availability_zone": "us-east-1e", "host.id": "i-07d3301208fe0a55a", "host.type": "t2.large" } } } ``` ## [Memory Info Context](https://develop.sentry.dev/sdk/foundations/transport/event-payloads/contexts.md#memory-info-context) The memory info context captures detailed information about memory usage and garbage collection metrics in an application at the time an event occurs. This is particularly useful for diagnosing memory-related issues in managed runtime environments. The `type` and default key is `"memory_info"`. * `allocated_bytes` Currently allocated memory. * `compacted` Boolean indicating if memory was compacted. * `concurrent` Boolean indicating if concurrent garbage collection occurred. * `finalization_pending_count` Number of objects awaiting finalization. * `fragmented_bytes` Fragmented memory that cannot be used. * `heap_size_bytes` Total heap size. * `high_memory_load_threshold_bytes` Threshold for high memory load detection. * `index` GC generation index. * `memory_load_bytes` Current memory load. * `pause_durations` Array of GC pause durations in milliseconds. * `pause_time_percentage` Percentage of time spent in GC pauses. * `pinned_objects_count` Number of pinned objects in memory. * `promoted_bytes` Bytes promoted to higher generation. * `total_allocated_bytes` Total memory allocated since start. * `total_available_memory_bytes` Total memory available to the application. * `total_committed_bytes` Total committed virtual memory. **Example Memory Info Context** ```json { "contexts": { "memory_info": { "type": "memory_info", "allocated_bytes": 1048576, // 1 MiB "total_allocated_bytes": 9437184, // 9 MiB "heap_size_bytes": 3145728, // 3 MiB "pinned_objects_count": 150, "pause_time_percentage": 25.5, "compacted": true, "concurrent": true, "pause_durations": [10, 5, 3] } } } ``` ## [Thread Pool Info Context](https://develop.sentry.dev/sdk/foundations/transport/event-payloads/contexts.md#thread-pool-info-context) The thread pool info context captures detailed metrics about the thread pool state at the moment an event occurs. This context is useful for investigating performance bottlenecks, thread starvation, and resource contention issues in multi-threaded applications. The `type` and default key is `"threadpool_info"`. * `available_worker_threads` Number of worker threads currently available in the thread pool. Worker threads are used for executing application code and handling CPU-bound tasks. * `available_completion_port_threads` Number of completion port threads (also known as I/O completion port threads) currently available. These threads handle I/O operations and asynchronous callbacks. * `max_worker_threads` Maximum number of worker threads the thread pool can have. This represents the upper limit for worker thread allocation. * `max_completion_port_threads` Maximum number of completion port threads the thread pool can maintain. This sets the ceiling for I/O completion port thread allocation. * `min_worker_threads` Minimum number of worker threads maintained by the thread pool. The thread pool will always keep at least this many worker threads active. * `min_completion_port_threads` Minimum number of completion port threads maintained by the thread pool. This ensures a baseline number of threads are available for I/O operations. **Example Thread Pool Info Context** ```json { "contexts": { "threadpool_info": { "available_worker_threads": 1022, "available_completion_port_threads": 1000, "max_worker_threads": 1023, "max_completion_port_threads": 1000, "min_worker_threads": 1, "min_completion_port_threads": 1 } } } ``` ## [Trace Context](https://develop.sentry.dev/sdk/foundations/transport/event-payloads/contexts.md#trace-context) Additional information that allows Sentry to connect multiple transactions, spans, and/or errors into one trace. **Important:** If the trace context is missing, relay will drop the transaction. * `trace_id` *Required*. The trace ID. Determines which `trace` the Span/Transaction belongs to. The value should be 16 random bytes encoded as a hex string (32 characters long). - Example: `"8f431b7aa08441bbbd5a0100fd91f9fe"` * `span_id` *Required*. The ID of the span or transaction. For non-transaction events, and if performance monitoring is disabled, it may still be desired to attach events to a trace via a trace ID. In these cases, you still need to provide a span ID. This span ID can effectively be entirely random and doesn't need to relate to an actual span, however, it is recommended to consider using the same span ID for multiple events within the same unit-of-execution (e.g. a request). [See the context propagation docs](https://develop.sentry.dev/sdk/foundations/trace-propagation.md#trace-data-on-events) for more details. - Example: `"bb8f278130535c3c"` * `parent_span_id` *Optional*. The ID of the span enclosing this span. - Example: `null` or `"a8972eefa820e2ff"` * `op` *Optional*. Short code identifying the type of operation the span is measuring. For more details, see [Sentry's conventions around span operations](https://develop.sentry.dev/sdk/performance/span-operations.md). - Example: `"http.server"` * `status` *Optional*. Whether the trace failed or succeeded. Currently only used to indicate status of individual transactions. - Example: `"ok"` - List of available status plus description: | State | Description | HTTP status code equivalent | | ---------------------------- | ------------------------------------------------------------------------------------------------------------ | --------------------------- | | `ok` | Not an error, returned on success | 200 and 2XX HTTP statuses | | `cancelled` | The operation was cancelled, typically by the caller | 499 | | `unknown` or `unknown_error` | An unknown error raised by APIs that don't return enough error information | 500 | | `invalid_argument` | The client specified an invalid argument | 400 | | `deadline_exceeded` | The deadline expired before the operation could succeed | 504 | | `not_found` | Content was not found or request was denied for an entire class of users | 404 | | `already_exists` | The entity attempted to be created already exists | 409 | | `permission_denied` | The caller doesn't have permission to execute the specified operation | 403 | | `resource_exhausted` | The resource has been exhausted e.g. per-user quota exhausted, file system out of space | 429 | | `failed_precondition` | The client shouldn't retry until the system state has been explicitly handled | 400 | | `aborted` | The operation was aborted | 409 | | `out_of_range` | The operation was attempted past the valid range e.g. seeking past the end of a file | 400 | | `unimplemented` | The operation is not implemented or is not supported/enabled for this operation | 501 | | `internal_error` | Some invariants expected by the underlying system have been broken. This code is reserved for serious errors | 500 | | `unavailable` | The service is currently available e.g. as a transient condition | 503 | | `data_loss` | Unrecoverable data loss or corruption | 500 | | `unauthenticated` | The requester doesn't have valid authentication credentials for the operation | 401 | * `origin` *Optional*. The origin of the trace indicates what created the trace. For more details, see [trace origin](https://develop.sentry.dev/sdk/performance/trace-origin.md). * `data` *Optional*. The map of custom provided data. Currently Sentry SDKs can set following fields: | Field | Type | Description | | ---------------- | ----------------- | ------------------------------------------------------------ | | `route` | `string` or `map` | The current route in the application. | | `previous_route` | `string` or `map` | The previous route in the application the user was visiting. | The `route` currently supports the following predefined fields if it's a map: | Field | Type | Description | | -------- | -------- | ---------------------------------------------- | | `name` | `string` | The name of the route in the user application. | | `params` | `map` | Params assigned to this route. | If the route is set to a string (e.g. `"route": "foo"`), it will be normalized into a map (e.g. `"route": {"name": "foo"}`) server-side. **Example Trace Context** ```json { "contexts": { "trace": { "trace_id": "12312012123120121231201212312012", "span_id": "0415201309082013", "parent_span_id": null, "description": "", "op": "http.server", "origin": "auto.http.http_client_5", "data": { "route": { "name": "HomeRoute" } } } } } ``` ## [Unity Context](https://develop.sentry.dev/sdk/foundations/transport/event-payloads/contexts.md#unity-context) The Unity context captures Unity game engine environment details for Unity-specific issue diagnosis. This context is useful for investigating graphics issues, performance problems, version compatibility, and platform-specific behavior in Unity applications. The `type` and default key is `"unity"`. * `copy_texture_support` Graphics texture copying capabilities. * `editor_version` Unity Editor version. * `install_mode` Distribution method. * `is_main_thread` Whether the event occurred on the main thread. * `rendering_threading_mode` Rendering pipeline configuration. * `target_frame_rate` Target FPS setting. **Example Unity Context** ```json { "contexts": { "unity": { "copy_texture_support": "Basic, Copy3D, DifferentTypes, TextureToRT, RTToTexture", "editor_version": "2022.1.23f1", "install_mode": "Store", "is_main_thread": true, "rendering_threading_mode": "LegacyJobified", "target_frame_rate": "-1" } } } ``` ## [Replay Context](https://develop.sentry.dev/sdk/foundations/transport/event-payloads/contexts.md#replay-context) Replay context contains the replay\_id of the associated replay with the event. The only and required field is `replay_id`. This should not be sent by SDKs in most cases, as the Dynamic Sampling Context will be plucked in relay, but for current versions of python and PHP these SDKs will send this context as they do not currently support the envelope endpoint. * `replay_id` **Required**. The replay\_id associated with the event. **Example Replay Context** ```json { "contexts": { "replay": { "replay_id": "12312012123120121231201212312012" } } } ``` ## [Page Context](https://develop.sentry.dev/sdk/foundations/transport/event-payloads/contexts.md#page-context) Page context contains information about the page that the event occurred on. * `url` **Required.** The URL of the page that the event occurred on, excluding query parameters & fragment. - Example: `https://sentry.io/issues` * `http.query` **Optional.** The query parameters of the page that the event occurred on. - Example: `?page=1` * `http.fragment` **Optional.** The fragment of the page that the event occurred on. - Example: `#123` * `referer` *Optional*. The referer of the page that the event occurred on. - Example: `https://sentry.io/` **Example Page Context** ```json { "contexts": { "page": { "url": "https://sentry.io/issues", "http.query": "?page=1", "http.fragment": "#123", "referer": "https://sentry.io/" } } } ``` ## [Response Context](https://develop.sentry.dev/sdk/foundations/transport/event-payloads/contexts.md#response-context) Response context contains information about the HTTP response associated with the event. This is mostly set on transactions in a web server environment where one transaction represents a HTTP request/response cycle. * `cookies` *Optional*. The cookie values. Can be passed, unparsed, as a string, as a dictionary, or as a list of tuples. - Example: `{ "PHPSESSID": "12345", "csrftoken": "1234567" }` * `headers` *Optional*. A dictionary of submitted headers. If a header appears multiple times it, needs to be merged according to the HTTP standard for header merging. Sentry treats header names as case-insensitive. - Example: `{ "Content-Type": "text/plain" }` * `status_code` **Required.** The integer status code from the HTTP response associated with the event. - Example: `200` * `body_size` *Optional*. HTTP response body size in bytes. - Example: `1000` * `data` *Optional*. Response data in any format that makes sense. SDKs should discard large and binary bodies by default. Can be given as a string or structural data of any format. - Example: `"Invalid request"` **Example Response Context** ```json { "contexts": { "response": { "cookies": { "PHPSESSID": "12345", "csrftoken": "1234567" }, "headers": { "Content-Type": "text/plain" }, "status_code": 500, "body_size": 1000, "data": "Invalid request" } } } ``` ## [Missing Instrumentation Context](https://develop.sentry.dev/sdk/foundations/transport/event-payloads/contexts.md#missing-instrumentation-context) Context contains information about missing or failed OTEL instrumentation. The required field is `package` which should contain the package or framework where a missing instrumentation was detected. * `package` **Required.** The package or framework where a missing instrumentation was detected. - Example: `express` * `javascript.is_cjs` *Optional*. Boolean that indicates if the context was added from a commonjs module. - Example: `true` **Example Response Context** ```json { "contexts": { "missing_instrumentation": { "package": "express", "javascript.is_cjs": true } } } ``` ## [Feature Flag Context](https://develop.sentry.dev/sdk/foundations/transport/event-payloads/contexts.md#feature-flag-context) The feature flag context contains information about the flags evaluated prior to an error occurring. Flag evaluation results are placed into the `values` key which is an array of 0 or more flag evaluation result objects. * `flag` **Required.** The name of the flag which was evaluated. - Example: `"feature-is-enabled"` * `result` **Required.** The boolean result of flag evaluation. - Example: `false` **Example Feature Flag Context** ```json { "contexts": { "flags": { "values": [ { "flag": "my_flag_name", "result": true } ] } } } ```