Custom contexts allow you to attach arbitrary data to an event. Often, this context is shared among any issue captured in its lifecycle. You cannot search these, but they are viewable on the issue page:
If you need to be able to search on custom data, use tags instead.
The best practice to attach custom data is via structured contexts. A context must always be a dictionary or map, and its values can be arbitrary.
SetContext and give the context a unique name:
USentrySubsystem* SentrySubsystem = ...; TMap<FString, FString> ContextData; AdditionalData.Add("Class", "Paladin"); AdditionalData.Add("Role", "Taunt"); SentrySubsystem->SetContext("Character", ContextData);
The same result can be achieved by calling corresponding function in blueprint:
Alternatively, this configuration cab be provided to the crash reporter during initialization.
Sentry's SDK automatically attaches certain context values such as
Target Type, to name a few, to all events.
There are no restrictions on context name. In the context object, all keys are allowed except for
type, which is used internally.
Learn more about conventions for common contexts in the contexts interface developer documentation.
When sending context, consider payload size limits. Sentry does not recommend sending the entire application state and large data blobs in contexts. If you exceed the maximum payload size, Sentry will respond with HTTP error
413 Payload Too Large and reject the event.
The Sentry SDK will try its best to accommodate the data you send and trim large context payloads. Some SDKs can truncate parts of the event; for more details, see the developer documentation on SDK data handling.
Additional Data is deprecated in favor of structured contexts.
Sentry used to support adding unstructured "Additional Data" via
Our documentation is open source and available on GitHub. Your contributions are welcome, whether fixing a typo (drat!) to suggesting an update ("yeah, this would be better").