> ## Documentation Index > Fetch the complete documentation index at: https://tyk.io/docs/llms.txt > Use this file to discover all available pages before exploring further. # Logs > Learn about the different types of logs in Tyk, how to configure them and how to integrate with third-party log management tools for effective API observability. A log is a timestamped text record, either structured (recommended) or unstructured, with some metadata. ## Types of Logs Tyk generates four types of logs: * **[Application Log](https://tyk.io/docs/api-management/logs/application-logs.md):** Internal system events such as health-checks, configuration changes, and errors. * **[API Traffic Log](https://tyk.io/docs/api-management/dashboard-analytics.md#where-the-data-comes-from):** Gateway A record of every API request, written into Redis and processed by Tyk Pump for analytics and reporting. * **[Access Log](https://tyk.io/docs/api-management/logs/access-logs.md):** Gateway Per-request server logs intended for external log aggregators. Similar to API Traffic Logs in that both record individual requests, but Access Logs are lightweight and real-time whereas API Traffic Logs are richer and processed asynchronously. * **[Audit Log](https://tyk.io/docs/api-management/logs/audit-logs.md):** Dashboard A record of user actions in Tyk Dashboard, such as API changes and login events. ## Configuring Application and Access Logs Tyk Gateway, Tyk Pump, Tyk Dashboard, Tyk MDCB, and Tyk Developer Portal each write an **Application Log** to `stderr`, handled in a typical installation by the service manager running the process. Tyk Gateway's **Access Log** uses the same underlying logger, so every setting that applies to Tyk Gateway's Application Log also affects the Access Log. Three aspects can be configured: * **verbosity**: which severity levels are written * **format**: the structure and content of each entry * **log output**: where logs are sent, for example to a third-party aggregator Both verbosity and format can be controlled globally across all components, or per component for finer control. Global settings take priority over component-specific ones. ### Global Settings Two environment variables apply across multiple components and override any component-specific setting: | Setting | Environment variable | Applies to | | :- | :- | :- | | Verbosity | `TYK_LOGLEVEL` | All components except Tyk Developer Portal | | Format | `TYK_LOGFORMAT` | Tyk Gateway, Tyk Dashboard, Tyk Pump | ### Component Settings When global variables are not set, each component can be configured individually using environment variables or the equivalent `log_level` and `log_format` settings in its configuration file. All components default to `info` verbosity and `text` format. Tyk Developer Portal is an exception: it defaults to `prod` format, which is equivalent to `json`. | Tyk component | Log level env var | Log format env var | Supported formats | | :- | :- | :- | :- | | [Tyk Gateway](https://tyk.io/docs/tyk-oss-gateway/configuration.md#log_level) | `TYK_GW_LOGLEVEL` | `TYK_GW_LOGFORMAT` | `text`, `json`, `legacy` | | [Tyk Pump](https://tyk.io/docs/tyk-pump/tyk-pump-configuration/tyk-pump-environment-variables.md#log_level) | `TYK_PMP_LOGLEVEL` | `TYK_PMP_LOGFORMAT` | `text`, `json`, `legacy` | | [Tyk Dashboard](https://tyk.io/docs/tyk-dashboard/configuration.md) | `TYK_DB_LOGLEVEL` (from `v5.14.0`) | `TYK_DB_LOGFORMAT` | `text`, `json` | | [Tyk MDCB](https://tyk.io/docs/tyk-multi-data-centre/mdcb-configuration-options.md#log_level) | `TYK_MDCB_LOGLEVEL` | N/A | Legacy text only | | [Tyk Developer Portal](https://tyk.io/docs/product-stack/tyk-enterprise-developer-portal/deploy/configuration.md#portal_log_level) | `PORTAL_LOG_LEVEL` | `PORTAL_LOG_FORMAT` | `text`, `json` | > [!NOTE] > > The `legacy` format was introduced in Tyk Gateway 5.14.0 and Tyk Pump 5.14.0 to maintain backward compatibility for existing users with log pipelines reliant on the precise log content. See [legacy format](https://tyk.io/docs/api-management/logs.md#legacy-format). ### Severity and Verbosity The severity of a log is an indication of its likely importance to the system administrator. The system will generate logs at four different levels of severity: | Severity | Purpose | Example | | :- | :- | :- | | Error | Conditions that require immediate attention, such as a component being unreachable or a request failing due to a system fault. | Failed to connect to Redis | | Warning | Potential issues or degraded behavior that may require investigation, but do not prevent the system from operating. | Configuration value out of bounds, using default | | Information | Normal operational events confirming the system is functioning as expected. This is the default level. | Gateway started, API loaded, access log entries | | Debug | Detailed diagnostic output useful for troubleshooting, such as middleware execution steps and request routing decisions. | Middleware execution details | Each component can individually be configured to output only the logs generated at or above a given severity level by setting the **log level** as follows: * `error`: only errors are logged * `warn`: warnings and errors are logged * `info`: errors, warnings, and informational messages are logged (default) * `debug`: all of the above, plus detailed diagnostic output > [!NOTE] > > Access Logs have `info` level severity. Setting Tyk Gateway's log level to `warn` or `error` therefore suppresses Access Log output. There are additional controls for the generation and content of access logs as described in [Access Logs](https://tyk.io/docs/api-management/logs/access-logs.md). > [!WARNING] > > Debug log level generates a significant amount of data and is not recommended unless debugging. ### Format Options Log format controls the structure and timestamp style of application and access logs generated by a component. The supported values are `text` (default), `json` (recommended), and `legacy`. > [!TIP] > > As a general performance tip, the `json` output format incurs less memory allocation overhead than the `text` format. For optimal performance, it's recommended to configure logging in the JSON format. > [tab] Text Format > > ``` > time="2024-09-05T09:04:12Z" level=info message="Tyk API Gateway v5.14.0" prefix=main > ``` > [tab] JSON Format > > ```json theme={null} > {"level":"info","message":"Tyk API Gateway v5.14.0","prefix":"main","time":"2024-09-05T09:04:12Z"} > ``` > [tab] Legacy Format > > Preserves the previous timestamp format and `msg` field key: > > ``` > time="Sep 05 09:04:12" level=info msg="Tyk API Gateway v5.14.0" prefix=main > ``` #### Legacy Format From Tyk Gateway 5.14.0 and Tyk Pump 5.14.0, the `text` and `json` formats use RFC3339 timestamps and a standardized `message` field. If your log pipeline relies on the previous timestamp format (`Dec 12 13:50:45`) or the `msg` field key, set `log_format` to `legacy` to preserve the old behavior. ### Log Output By default, application and access log output is written to `stderr`. Tyk Gateway and Dashboard can also forward logs to a third-party aggregator, in addition to `stderr`: | Data Sink | Gateway | Dashboard | | :- | :-: | :-: | | Sentry | ✅ | ✅ | | Logstash | ✅ | ❌ | | Graylog | ✅ | ❌ | | Syslog | ✅ | ❌ | Add the relevant settings to `tyk.conf` for Tyk Gateway, or `tyk_analytics.conf` for Tyk Dashboard (or use the equivalent environment variables): > [tab] Sentry > > GatewayDashboard > > * `use_sentry`: Set to `true` to enable output to [Sentry](https://sentry.io/product/logs/). > * `sentry_code`: The Sentry-assigned DSN (endpoint URL) to which the logs are sent. > [tab] Logstash > > Gateway Only > > * `use_logstash`: Set to `true` to enable output to [Logstash](https://www.elastic.co/logstash). > * `logstash_transport`: Set this to `"tcp"`. > * `logstash_network_addr`: The network address of the Logstash server, in the form `hostname:port`. > [tab] Graylog > > Gateway Only > > * `use_graylog`: Set to `true` to enable output to [Graylog](https://graylog.org/). > * `graylog_network_addr`: The network address of the Graylog server, in the form `hostname:port`. > [tab] Syslog > > Gateway Only > > * `use_syslog`: Set to `true` to enable output to syslog. > * `syslog_transport`: Set to `"udp"` to send to a remote syslog server, or leave empty to use the local Unix socket. > * `syslog_network_addr`: The network address of the syslog server, in the form `hostname:port`. ## Configuring Traffic Logs Traffic Logs are generated by Tyk Gateway and written to Redis, not `stderr`, so none of the settings above apply to them. Enable them by setting [`enable_analytics`](https://tyk.io/docs/tyk-oss-gateway/configuration#enable_analytics) in the Gateway configuration; see [Dashboard Analytics](https://tyk.io/docs/api-management/dashboard-analytics.md) for how Tyk Pump then processes and routes them from Redis. ## Configuring Audit Logs Audit Logs are generated by Tyk Dashboard and configured through its own `audit.*` settings block, unrelated to the Application Log settings above. See [Audit Logs](https://tyk.io/docs/api-management/logs/audit-logs.md) for the full configuration reference, or [Enable and View Audit Logs in Tyk Dashboard](https://tyk.io/docs/api-management/enable-audit-logs-dashboard.md) for a step-by-step guide.