---
title: "Options"
description: "Learn more about how the Sentry Native SDK can be configured via options. These are being passed to the init function and therefore set when the SDK is first initialized."
url: https://docs.sentry.io/platforms/native/guides/qt/configuration/options/
---

# Options for Qt

Options are passed into `sentry_init` as a pointer to an options object created via `sentry_options_new()`. There are functions that allow to set all options individually.

```c
#include <sentry.h>

int main(void) {
  sentry_options_t *options = sentry_options_new();
  sentry_options_set_dsn(options, "https://<key>@o<orgId>.ingest.sentry.io/<projectId>");
  sentry_options_set_release(options, "my-project-name@2.3.12");
  sentry_options_set_debug(options, 1);
  sentry_init(options);

  /* ... */
}
```

## [Core Options](https://docs.sentry.io/platforms/native/guides/qt/configuration/options.md#core-options)



Options that can be read from an environment variable (`SENTRY_DSN`, `SENTRY_ENVIRONMENT`, `SENTRY_RELEASE`) are read automatically.

### [dsn](https://docs.sentry.io/platforms/native/guides/qt/configuration/options.md#dsn)

| Type | `string` |
| ---- | -------- |

The DSN tells the SDK where to send the events. If this value is not provided, the SDK will try to read it from the `SENTRY_DSN` environment variable. If that variable also does not exist, the SDK will just not send any events.

Learn more about [DSN utilization](https://docs.sentry.io/concepts/key-terms/dsn-explainer.md#dsn-utilization).

### [database\_path](https://docs.sentry.io/platforms/native/guides/qt/configuration/options.md#database_path)

| Type    | `string`         |
| ------- | ---------------- |
| Default | `.sentry-native` |

Allows you to specify a path to the local event- and crash-database of the Native SDK. This path will default to `.sentry-native` relative to the current working directory (`CWD`). While this is a convenient setting for development, we strongly urge you to provide an explicit database path for our production deployments. In many deployment scenarios, the path relative to the `CWD` will not be writable. For this reason, you should store the database in your application's user-specific data/cache directory (e.g., under `%AppData%\Local` on Windows, `~/Library/Application Support` on macOS, or `XDG_CACHE_HOME` on Linux).

### [debug](https://docs.sentry.io/platforms/native/guides/qt/configuration/options.md#debug)

| Type    | `bool`  |
| ------- | ------- |
| Default | `false` |

Turns debug mode on or off. If `debug` is enabled, the SDK will attempt to print out useful debugging information if something goes wrong. If you run a debug-build (`NDEBUG` isn't defined), it will default to `true`; otherwise, the default is always `false`. You can provide a `SENTRY_DEBUG` environment variable with either `"0"` or `"1"` for "off" and "on" respectively, which will override the defaults. It's generally not recommended to turn it on in production, though turning `debug` mode on will not cause any safety concerns. You can limit the output by setting `logger_level` to an appropriate level for your production use case.

### [logger\_level](https://docs.sentry.io/platforms/native/guides/qt/configuration/options.md#logger_level)

| Type    | `sentry_level_t`     |
| ------- | -------------------- |
| Default | `SENTRY_LEVEL_DEBUG` |

Sets the minimum level of the debug messages the SDK logs. Has no effect unless `debug` is enabled.

### [logger](https://docs.sentry.io/platforms/native/guides/qt/configuration/options.md#logger)

| Type | `function` |
| ---- | ---------- |

This function is called with the level, the format string, and the arguments of each debug message, and replaces the default logger, which prints to `stderr` or, on Android, to logcat. It's only called when `debug` is enabled. Multiple threads may call it concurrently.

### [logger\_enabled\_when\_crashed](https://docs.sentry.io/platforms/native/guides/qt/configuration/options.md#logger_enabled_when_crashed)

| Available since | `0.11.0`                             |
| --------------- | ------------------------------------ |
| Type            | `bool`                               |
| Default         | `true` (false for breakpad on macOS) |

Whether the SDK keeps calling the logger after it detects a crash. Disabling it avoids potential issues that logging might cause during crash handling.

### [release](https://docs.sentry.io/platforms/native/guides/qt/configuration/options.md#release)

| Type | `string` |
| ---- | -------- |

Sets the release. Release names are strings, but some formats are detected by Sentry and might be rendered differently. Learn more about how to send release data so Sentry can tell you about regressions between releases and identify the potential source in [the releases documentation](https://docs.sentry.io/product/releases.md) or the [sandbox](https://sandbox.sentry.io/?scenario=releases\&source=docs).

By default the SDK will try to read this value from the `SENTRY_RELEASE` environment variable.

### [environment](https://docs.sentry.io/platforms/native/guides/qt/configuration/options.md#environment)

| Type    | `string`     |
| ------- | ------------ |
| Default | `production` |

Sets the environment. This string is freeform and set by default. A release can be associated with more than one environment to separate them in the UI (think `staging` vs `prod` or similar).

By default the SDK will try to read this value from the `SENTRY_ENVIRONMENT` environment variable. Otherwise, the default environment is `production`.

### [dist](https://docs.sentry.io/platforms/native/guides/qt/configuration/options.md#dist)

| Type | `string` |
| ---- | -------- |

Sets the distribution of the application. Distributions are used to disambiguate build or deployment variants of the same release of an application.

### [sample\_rate](https://docs.sentry.io/platforms/native/guides/qt/configuration/options.md#sample_rate)

| Type    | `float` |
| ------- | ------- |
| Default | `1.0`   |

Configures the sample rate for error events, in the range of `0.0` to `1.0`. The default is `1.0`, which means that 100% of error events will be sent. If set to `0.1`, only 10% of error events will be sent. Events are picked randomly.

### [max\_breadcrumbs](https://docs.sentry.io/platforms/native/guides/qt/configuration/options.md#max_breadcrumbs)

| Type    | `int` |
| ------- | ----- |
| Default | `100` |

This variable controls the total amount of breadcrumbs that should be captured. This defaults to `100`, but you can set this to any number. However, you should be aware that Sentry has a [maximum payload size](https://develop.sentry.dev/sdk/data-model/envelopes/#size-limits) and any events exceeding that payload size will be dropped.

### [send\_client\_reports](https://docs.sentry.io/platforms/native/guides/qt/configuration/options.md#send_client_reports)

| Available since | `0.13.6` |
| --------------- | -------- |
| Type            | `bool`   |
| Default         | `true`   |

Set this boolean to `false` to disable client reports. Client reports are a protocol feature that allows clients to send status information about themselves to Sentry. They’re currently used mainly to report outcomes for events that were never sent.

### [require\_user\_consent](https://docs.sentry.io/platforms/native/guides/qt/configuration/options.md#require_user_consent)

| Type    | `bool`  |
| ------- | ------- |
| Default | `false` |

Disables uploads until the user has given consent to the SDK. Give consent with `sentry_user_consent_give` and revoke it with `sentry_user_consent_revoke`. The SDK discards envelopes captured before consent is given, unless [offline caching](https://docs.sentry.io/platforms/native/configuration/transports.md#offline-caching) or [HTTP retry](https://docs.sentry.io/platforms/native/configuration/transports.md#retrying-failed-uploads) is enabled.

### [attach\_stacktrace](https://docs.sentry.io/platforms/native/guides/qt/configuration/options.md#attach_stacktrace)

| Available since | `0.17.4` |
| --------------- | -------- |
| Type            | `bool`   |
| Default         | `false`  |

Attaches the stack trace of the capturing thread to events that carry none, such as messages. Events that already carry a stack trace, including crashes, are left untouched. With a stack trace, messages group by call site rather than by message text.

### [shutdown\_timeout](https://docs.sentry.io/platforms/native/guides/qt/configuration/options.md#shutdown_timeout)

| Type    | `uint64_t`            |
| ------- | --------------------- |
| Default | `2000` (milliseconds) |

Sets the maximum time, in milliseconds, that `sentry_close()` waits for asynchronous tasks, such as pending uploads, to finish before it attempts a forced termination.

### [logs\_with\_attributes](https://docs.sentry.io/platforms/native/guides/qt/configuration/options.md#logs_with_attributes)

| Type    | `bool`  |
| ------- | ------- |
| Default | `false` |

Whether calls to `sentry_log_X()` expect an attributes object as the second argument, allowing users to pass in custom log attributes. An example can be found on the [Logs page](https://docs.sentry.io/platforms/native/logs.md#additional-attributes).

## [Hooks](https://docs.sentry.io/platforms/native/guides/qt/configuration/options.md#hooks)

These options can be used to hook the SDK in various ways to customize the reporting of events.

### [before\_send](https://docs.sentry.io/platforms/native/guides/qt/configuration/options.md#before_send)

| Type | `function` |
| ---- | ---------- |

This function is called with an SDK-specific message or error event object and a hint, and can return a modified event object, or `sentry_value_new_null()` to skip reporting the event. To drop it, you **must** call `sentry_value_decref(event)` before returning. This hook can be used, for instance, for manual PII stripping before sending.

By the time `before_send` is executed, all scope data has already been applied to the event. Further modification of the scope won't have any effect.

### [on\_crash](https://docs.sentry.io/platforms/native/guides/qt/configuration/options.md#on_crash)

| Type | `function` |
| ---- | ---------- |

This function is called with a backend-specific event object and a hint, and can return a modified event object, or `sentry_value_new_null()` to skip reporting the event. To drop it, you **must** call `sentry_value_decref(event)` before returning. In contrast to `before_send`, it is only called when a crash occurred. You can find detailed information concerning its usage in [Filtering](https://docs.sentry.io/platforms/native/configuration/filtering.md#using-on_crash).

### [before\_transaction](https://docs.sentry.io/platforms/native/guides/qt/configuration/options.md#before_transaction)

| Type | `function` |
| ---- | ---------- |

This function is called with an SDK-specific transaction event object, and can return a modified transaction event object, or `sentry_value_new_null()` to skip reporting the event. To drop it, you **must** call `sentry_value_decref(tx)` before returning. One way this might be used is for manual PII stripping before sending.

### [before\_send\_feedback](https://docs.sentry.io/platforms/native/guides/qt/configuration/options.md#before_send_feedback)

| Available since | `0.16.2`   |
| --------------- | ---------- |
| Type            | `function` |

This function is called with a feedback event and a hint, and can return a modified event, or `sentry_value_new_null()` to drop the feedback. The feedback itself is nested under the event's `contexts.feedback`. To drop it, you **must** call `sentry_value_decref(event)` before returning. Use the hint to add attachments.

User feedback does not go through `before_send`, so this is the only hook that sees it. See [Filtering](https://docs.sentry.io/platforms/native/configuration/filtering.md#using-before-send-feedback).

### [before\_send\_log](https://docs.sentry.io/platforms/native/guides/qt/configuration/options.md#before_send_log)

| Type | `function` |
| ---- | ---------- |

This function is called with an SDK-specific log object, and can return a modified log object, or `sentry_value_new_null()` to drop the log. In that case, you **must** call `sentry_value_decref(log)` before returning.

### [before\_send\_metric](https://docs.sentry.io/platforms/native/guides/qt/configuration/options.md#before_send_metric)

| Available since | `0.12.6`   |
| --------------- | ---------- |
| Type            | `function` |

This function is called with an SDK-specific metric object, and can return a modified metric object, or `sentry_value_new_null()` to drop the metric. In that case, you **must** call `sentry_value_decref(metric)` before returning. An example can be found on the [Metrics page](https://docs.sentry.io/platforms/native/metrics.md#before_send_metric).

### [before\_breadcrumb](https://docs.sentry.io/platforms/native/guides/qt/configuration/options.md#before_breadcrumb)

| Available since | `0.13.0`   |
| --------------- | ---------- |
| Type            | `function` |

This function is called with each breadcrumb passed to `sentry_add_breadcrumb()`, and can return a modified breadcrumb, or `sentry_value_new_null()` to drop it. To drop it, you **must** call `sentry_value_decref(breadcrumb)` before returning.

### [before\_screenshot](https://docs.sentry.io/platforms/native/guides/qt/configuration/options.md#before_screenshot)

| Available since | `0.13.7`   |
| --------------- | ---------- |
| Type            | `function` |

This function is called with the event before a screenshot is captured for it, and should return non-zero to capture the screenshot or zero to skip it. It doesn't take ownership of the event. It's only called on Windows when [screenshots](https://docs.sentry.io/platforms/native/guides/qt/enriching-events/screenshots.md) are enabled, and isn't supported by the `crashpad` backend.

### [on\_crashed\_last\_run](https://docs.sentry.io/platforms/native/guides/qt/configuration/options.md#on_crashed_last_run)

| Available since | `0.16.4`   |
| --------------- | ---------- |
| Type            | `function` |

This function is called during `sentry_init()` for every envelope of a crash from a previous run. It doesn't take ownership of the envelope, which is only valid during the call. Because `sentry_init()` hasn't completed yet, the function must not call SDK functions that require an initialized SDK. With the `native` backend, the option must also be set in the run that crashed, so that the crash daemon keeps the envelope for the next launch.

### [initial\_scope](https://docs.sentry.io/platforms/native/guides/qt/configuration/options.md#initial_scope)

| Available since | `0.16.7`   |
| --------------- | ---------- |
| Type            | `function` |

This function is called once during `sentry_init()` with the global scope, before the crash backend starts, so the data it sets is available to crash reports, including those of out-of-process crash handlers. Configure the scope with the `sentry_scope_*` functions rather than global functions such as `sentry_set_tag`.

## [Crash Handling Options](https://docs.sentry.io/platforms/native/guides/qt/configuration/options.md#crash-handling-options)

### [symbolize\_stacktraces](https://docs.sentry.io/platforms/native/guides/qt/configuration/options.md#symbolize_stacktraces)

| Type    | `bool`                                                                       |
| ------- | ---------------------------------------------------------------------------- |
| Default | `false` (true with the native backend, and on Android, AIX, and PlayStation) |

Enables client-side symbolication of stack traces. This is useful for resolving system library frames when debug information files can't be provided for server-side symbolication. It can have a performance impact, because symbolication runs in the application process when the `inproc` backend handles a crash, or when you capture an event with any backend.

### [system\_crash\_reporter\_enabled](https://docs.sentry.io/platforms/native/guides/qt/configuration/options.md#system_crash_reporter_enabled)

| Type    | `bool`  |
| ------- | ------- |
| Default | `false` |

Forwards crashes to the macOS system crash reporter. Depending on the crash, this may increase the time it takes to handle it. This setting only affects the `crashpad` and `native` backends on macOS.

### [max\_stack\_capture\_size](https://docs.sentry.io/platforms/native/guides/qt/configuration/options.md#max_stack_capture_size)

| Available since | `0.17.2`              |
| --------------- | --------------------- |
| Type            | `uint32_t`            |
| Default         | `0` (bytes, no limit) |

Limits the size of the stack captured for each non-crashing thread. The crashed thread is not limited. Set to `0` for no limit. This setting only affects the `crashpad` and `native` backends on Linux.

### [handler\_strategy](https://docs.sentry.io/platforms/native/guides/qt/configuration/options.md#handler_strategy)

| Type    | `sentry_handler_strategy_t`       |
| ------- | --------------------------------- |
| Default | `SENTRY_HANDLER_STRATEGY_DEFAULT` |

Controls when the SDK invokes a previously installed signal handler. By default, it's invoked after the SDK has handled the signal. `SENTRY_HANDLER_STRATEGY_CHAIN_AT_START` invokes it first instead, which is needed for runtimes like CLR or Mono that convert some signals into managed exceptions. Otherwise, the SDK would report a native crash in addition to the managed exception. This setting only affects the `inproc` backend on Linux and Android, and the `native` backend on Linux.

### [crash\_memory\_reserve](https://docs.sentry.io/platforms/native/guides/qt/configuration/options.md#crash_memory_reserve)

| Available since | `0.17.6`              |
| --------------- | --------------------- |
| Type            | `size_t`              |
| Default         | `0` (bytes, disabled) |

Sets the amount of memory, in bytes, that the SDK reserves during `sentry_init()` and releases when it handles a crash, so the crash handler can still allocate after the application has run out of memory. Set to `0` to disable it. The default comes from the `SENTRY_CRASH_MEMORY_RESERVE` CMake option, which is set in KiB.

## [Native Backend Options](https://docs.sentry.io/platforms/native/guides/qt/configuration/options.md#native-backend-options)

These options only affect the [`native` backend](https://docs.sentry.io/platforms/native/configuration/backends/native.md).

### [crash\_reporting\_mode](https://docs.sentry.io/platforms/native/guides/qt/configuration/options.md#crash_reporting_mode)

| Available since | `0.13.2`                                           |
| --------------- | -------------------------------------------------- |
| Type            | `sentry_crash_reporting_mode_t`                    |
| Default         | `SENTRY_CRASH_REPORTING_MODE_NATIVE_WITH_MINIDUMP` |

Controls which crash report format the `native` backend sends when the application crashes. This setting only affects the `native` backend. See [Crash Reporting Modes](https://docs.sentry.io/platforms/native/configuration/backends/native.md#crash-reporting-modes).

### [minidump\_mode](https://docs.sentry.io/platforms/native/guides/qt/configuration/options.md#minidump_mode)

| Available since | `0.13.2`                     |
| --------------- | ---------------------------- |
| Type            | `sentry_minidump_mode_t`     |
| Default         | `SENTRY_MINIDUMP_MODE_SMART` |

Controls how much memory the `native` backend captures in minidumps. This setting only affects the `native` backend and crash reporting modes that send a minidump. See [Minidump Capture Modes](https://docs.sentry.io/platforms/native/configuration/backends/native.md#minidump-capture-modes).

### [thread\_stackwalk\_mode](https://docs.sentry.io/platforms/native/guides/qt/configuration/options.md#thread_stackwalk_mode)

| Available since | `0.16.5`                           |
| --------------- | ---------------------------------- |
| Type            | `sentry_thread_stackwalk_mode_t`   |
| Default         | `SENTRY_THREAD_STACKWALK_MODE_ALL` |

Controls which threads the `native` backend walks when it unwinds stacks on the client. With `SENTRY_THREAD_STACKWALK_MODE_CRASHED_ONLY`, only the crashed thread gets a stack trace, and the remaining threads are listed with their ID and name. This shortens crash processing for applications with many threads. This setting only affects the `native` backend and crash reporting modes with client-side stack walking.

### [crash\_upload\_mode](https://docs.sentry.io/platforms/native/guides/qt/configuration/options.md#crash_upload_mode)

| Available since | `0.15.0`                        |
| --------------- | ------------------------------- |
| Type            | `sentry_crash_upload_mode_t`    |
| Default         | `SENTRY_CRASH_UPLOAD_MODE_SYNC` |

Controls whether the crashed application waits for the `native` backend's crash daemon to finish uploading. With `SENTRY_CRASH_UPLOAD_MODE_ASYNC`, the application can exit as soon as the crash data has been captured, while the daemon continues the upload in the background. This setting only affects the `native` backend.

### [minidump\_flags](https://docs.sentry.io/platforms/native/guides/qt/configuration/options.md#minidump_flags)

| Available since | `0.16.0`                  |
| --------------- | ------------------------- |
| Type            | `sentry_minidump_flags_t` |

Sets the raw Windows [`MINIDUMP_TYPE`](https://learn.microsoft.com/en-us/windows/win32/api/minidumpapiset/ne-minidumpapiset-minidump_type) flags for minidumps. When set, these flags take precedence over `minidump_mode`. Unsupported bits are discarded, and `0` selects `MiniDumpNormal`. This setting only affects the `native` backend on Windows.

## [Crashpad Backend Options](https://docs.sentry.io/platforms/native/guides/qt/configuration/options.md#crashpad-backend-options)

These options only affect the [`crashpad` backend](https://docs.sentry.io/platforms/native/configuration/backends/crashpad.md).

### [crashpad\_wait\_for\_upload](https://docs.sentry.io/platforms/native/guides/qt/configuration/options.md#crashpad_wait_for_upload)

| Type    | `bool`  |
| ------- | ------- |
| Default | `false` |

Whether Crashpad should delay application shutdown until the upload of the crash report in the `crashpad_handler` is complete. This is useful for deployment in `Docker` (Linux and Windows containers) or `systemd`, where the life cycle of all processes is bound by the root process (typically the application being monitored).

### [crashpad\_limit\_stack\_capture\_to\_sp](https://docs.sentry.io/platforms/native/guides/qt/configuration/options.md#crashpad_limit_stack_capture_to_sp)

| Available since | `0.12.0` |
| --------------- | -------- |
| Type            | `bool`   |
| Default         | `false`  |

Uses the current stack pointer to bound the stack capture of the `crashpad` backend, instead of the full stack region derived from the thread environment block (TEB). This is useful when running under Wine or Proton, where incorrect TEB values can lead to excessively large stack captures. This setting only affects the `crashpad` backend on Windows.

## [Tracing Options](https://docs.sentry.io/platforms/native/guides/qt/configuration/options.md#tracing-options)

### [traces\_sample\_rate](https://docs.sentry.io/platforms/native/guides/qt/configuration/options.md#traces_sample_rate)

| Type    | `float` |
| ------- | ------- |
| Default | `0.0`   |

A number between `0.0` and `1.0`, controlling the percentage chance a given transaction will be sent to Sentry. (`0.0` represents 0% while `1.0` represents 100%.) Applies equally to all transactions created in the app. Either this or `traces_sampler` must be defined to enable tracing.

### [traces\_sampler](https://docs.sentry.io/platforms/native/guides/qt/configuration/options.md#traces_sampler)

| Type | `function` |
| ---- | ---------- |

A function responsible for determining the percentage chance a given transaction will be sent to Sentry. It will automatically be passed information about the transaction and the context in which it's being created, and must return a number between `0` (0% chance of being sent) and `1` (100% chance of being sent). Can also be used for filtering transactions, by returning 0 for those that are unwanted. Either this or `traces_sample_rate` must be defined to enable tracing. An example can be found in the [Sampling](https://docs.sentry.io/platforms/native/configuration/sampling.md#setting-a-sampling-function) section.

### [max\_spans](https://docs.sentry.io/platforms/native/guides/qt/configuration/options.md#max_spans)

| Type    | `size_t` |
| ------- | -------- |
| Default | `1000`   |

Sets the maximum number of spans that can be attached to a transaction.

### [propagate\_traceparent](https://docs.sentry.io/platforms/native/guides/qt/configuration/options.md#propagate_traceparent)

| Available since | `0.11.3` |
| --------------- | -------- |
| Type            | `bool`   |
| Default         | `false`  |

Controls whether the SDK should propagate the W3C `traceparent` HTTP header alongside the `sentry-trace` header for [distributed tracing](https://docs.sentry.io/platforms/native/tracing/trace-propagation/custom-instrumentation.md).

If your backend uses an OTel collector with tail-based sampling, see [Sentry with OTel](https://docs.sentry.io/concepts/otlp/sentry-with-otel.md) for an important interaction with this option.

### [strict\_trace\_continuation](https://docs.sentry.io/platforms/native/guides/qt/configuration/options.md#strict_trace_continuation)

| Available since | `0.14.1` |
| --------------- | -------- |
| Type            | `bool`   |
| Default         | `false`  |

Controls whether to continue an incoming trace when only one of the trace and the SDK has an organization ID. When enabled, the SDK starts a new trace in that case. When disabled, it continues the incoming trace. If both organization IDs are present and differ, the SDK never continues the trace. See [strict trace continuation](https://develop.sentry.dev/sdk/foundations/trace-propagation/#strict-trace-continuation).

### [org\_id](https://docs.sentry.io/platforms/native/guides/qt/configuration/options.md#org_id)

| Available since | `0.14.1` |
| --------------- | -------- |
| Type            | `string` |

Overrides the organization ID that the SDK derives from the DSN host, such as `123456` from `o123456.ingest.sentry.io`. This is typically only needed for self-hosted setups where the DSN host doesn't contain the organization ID.

## [App Hang Options](https://docs.sentry.io/platforms/native/guides/qt/configuration/options.md#app-hang-options)

These options control in-process app-hang detection. See the [App Hangs page](https://docs.sentry.io/platforms/native/app-hangs.md) for a full explanation and usage example.

### [enable\_app\_hang\_tracking](https://docs.sentry.io/platforms/native/guides/qt/configuration/options.md#enable_app_hang_tracking)

| Available since | `0.15.2` |
| --------------- | -------- |
| Type            | `bool`   |
| Default         | `false`  |

Enables or disables in-process app-hang detection. When enabled, a background watchdog thread monitors heartbeats from the watched thread. If no heartbeat is received within `app_hang_timeout`, an app-hang event is captured and sent to Sentry.

Must be combined with regular calls to `sentry_app_hang_heartbeat()` from the thread you want monitored. The first heartbeat latches the calling thread as the monitored thread; heartbeats from any other thread are ignored. To pause detection while the thread stops sending heartbeats on purpose, call `sentry_app_hang_pause()` (available since `0.16.1`).

### [app\_hang\_timeout](https://docs.sentry.io/platforms/native/guides/qt/configuration/options.md#app_hang_timeout)

| Available since | `0.15.2`              |
| --------------- | --------------------- |
| Type            | `uint64_t`            |
| Default         | `5000` (milliseconds) |

Sets the app-hang detection timeout, in milliseconds. If `enable_app_hang_tracking` is enabled and no heartbeat is received from the monitored thread within this window, an app-hang event is captured. The minimum is `1000` ms; the SDK raises lower values, including `0`, to `1000` ms.

## [Transport Options](https://docs.sentry.io/platforms/native/guides/qt/configuration/options.md#transport-options)

These options control how the HTTP transport retries and caches envelopes. See the [Transports page](https://docs.sentry.io/platforms/native/configuration/transports.md) for a full explanation and usage example.

### [http\_retry](https://docs.sentry.io/platforms/native/guides/qt/configuration/options.md#http_retry)

| Available since | `0.13.5` |
| --------------- | -------- |
| Type            | `bool`   |
| Default         | `false`  |

Enables or disables HTTP retry with exponential backoff for network failures. See [Retrying Failed Uploads](https://docs.sentry.io/platforms/native/configuration/transports.md#retrying-failed-uploads).

### [cache\_keep](https://docs.sentry.io/platforms/native/guides/qt/configuration/options.md#cache_keep)

| Available since | `0.12.7`                 |
| --------------- | ------------------------ |
| Type            | `sentry_cache_keep_t`    |
| Default         | `SENTRY_CACHE_KEEP_NONE` |

Controls if and when the SDK keeps envelopes in a persistent cache, in the `cache/` subdirectory of the database path. See [Offline Caching](https://docs.sentry.io/platforms/native/configuration/transports.md#offline-caching).

### [cache\_max\_items](https://docs.sentry.io/platforms/native/guides/qt/configuration/options.md#cache_max_items)

| Available since | `0.12.7` |
| --------------- | -------- |
| Type            | `size_t` |
| Default         | `30`     |

Sets the maximum number of items in the cache directory. On startup, the SDK removes cached entries from oldest to newest until the directory contains at most the specified number of items. Set to `0` for no limit. See [Offline Caching](https://docs.sentry.io/platforms/native/configuration/transports.md#offline-caching).

### [cache\_max\_size](https://docs.sentry.io/platforms/native/guides/qt/configuration/options.md#cache_max_size)

| Available since | `0.12.7`              |
| --------------- | --------------------- |
| Type            | `size_t`              |
| Default         | `0` (bytes, no limit) |

Sets the maximum size in bytes for the cache directory. On startup, the SDK removes cached entries from oldest to newest until the directory size is within the limit. Set to `0` for no limit. See [Offline Caching](https://docs.sentry.io/platforms/native/configuration/transports.md#offline-caching).

### [cache\_max\_age](https://docs.sentry.io/platforms/native/guides/qt/configuration/options.md#cache_max_age)

| Available since | `0.12.7`                |
| --------------- | ----------------------- |
| Type            | `time_t`                |
| Default         | `0` (seconds, no limit) |

Sets the maximum age in seconds for entries in the cache directory. On startup, the SDK removes cached entries exceeding the limit. Set to `0` for no limit. See [Offline Caching](https://docs.sentry.io/platforms/native/configuration/transports.md#offline-caching).

### [transfer\_timeout](https://docs.sentry.io/platforms/native/guides/qt/configuration/options.md#transfer_timeout)

| Available since | `0.15.0`                     |
| --------------- | ---------------------------- |
| Type            | `uint64_t`                   |
| Default         | `0` (milliseconds, no limit) |

Sets the timeout in milliseconds for HTTP transfers. With curl, it limits the total time a request may take. With WinHTTP, it applies to individual send and receive operations. Set to `0` for no limit. Crashpad's crash report upload doesn't support it.

### [ca\_certs](https://docs.sentry.io/platforms/native/guides/qt/configuration/options.md#ca_certs)

| Type | `string` |
| ---- | -------- |

Sets the path to a file containing the SSL certificates used for verification. Only the `curl` transport uses this option.

### [enable\_large\_attachments](https://docs.sentry.io/platforms/native/guides/qt/configuration/options.md#enable_large_attachments)

| Available since | `0.13.9` |
| --------------- | -------- |
| Type            | `bool`   |
| Default         | `false`  |

Uploads attachments above an internal size threshold in a separate request before the envelope is sent, instead of embedding them in the envelope. Without it, Sentry rejects oversized uploads. This requires the `projects:relay-upload-endpoint` server-side feature.