Skip to main content
A log is a timestamped text record, either structured (recommended) or unstructured, with some metadata. Tyk logs are written to stderr and stdout. In a typical installation, these will be handled by the service manager running the process.

​
Types of Logs

Tyk generates three types of logs:
  • Application Logs: Captures internal events of the system, such as health-checks, status, configuration changes, and errors, which are typically used for monitoring and debugging.
  • Access Logs: Traditional server logs that record basic information about each request to your API Gateway. Gateway Only
  • 404 Logs: A configuration option in Tyk Gateway that enables logging of HTTP 404 (Not Found) errors. Gateway Only
Tyk Gateway also generates API Traffic Logs, which are written into Redis for detailed information about API traffic and analysis. For more information on API Traffic Logs, refer to this documentation.

​
Configuring Logs

You can configure log verbosity and format for the following Tyk components:

​
Log Verbosity

Tyk can generate application logs at four levels of verbosity:
  • error is the most minimal level of logging, reporting only errors
  • warn will log warnings and errors
  • info logs errors, warnings and some additional information and is the default logging level
  • debug generates a high volume of logs for maximum visibility of what Tyk is doing when you need to debug an issue
Debug log level generates a significant amount of data and is not recommended unless debugging.
You can set the logging verbosity for each Tyk Component using the appropriate log_level setting in its configuration file (or the equivalent environment variable).
Tyk componentConfig optionEnvironment variableDefault value if unset
Tyk DashboardNot AvailableNot Availableinfo
Tyk Gatewaylog_levelTYK_GW_LOGLEVELinfo
Tyk Pumplog_levelTYK_PMP_LOGLEVELinfo
Tyk MDCBlog_levelTYK_MDCB_LOGLEVELinfo
Tyk Developer PortallogLevelPORTAL_LOG_LEVELinfo

​
Log Format

You can configure the format in which logs will be generated; it can be either text (default) or json (recommended).
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.
time="Sep 05 09:04:12" level=info msg="Tyk API Gateway v5.6.0" prefix=main
Tyk componentConfig optionEnvironment variableDefault value if unset
Tyk Gateway (from v5.6.0)log_formatTYK_GW_LOGFORMATtext
Tyk Pumplog_formatTYK_PMP_LOG_FORMATtext
Tyk Dashboard (System)log_formatTYK_DB_LOGFORMATtext
Tyk Dashboard (Audit)audit.formatTYK_DB_AUDIT_FORMATtext
Tyk MDCBNot AvailableNot Availabletext
Tyk Developer PortalLogFormatPORTAL_LOG_FORMATprod (equivalent to json)

​
Application Logs

Application logs capture internal events of the system, such as health-checks, status, configuration changes, and errors, which are typically used for monitoring and debugging. Example 
time="Feb 16 22:48:39" level=info msg="Using Policies from Dashboard Service" prefix=main
time="Feb 16 22:48:39" level=info msg="Calling dashboard service for policy list" prefix=policy
time="Feb 16 22:48:39" level=info msg="Processing policy list" prefix=policy
time="Feb 16 22:48:39" level=info msg="Policies found (5 total):" prefix=main

​
Access Logs

Gateway Only Access logs are simple, traditional server logs that record basic information about each request to your API Gateway and are written directly to stdout/stderr. As of Tyk Gateway v5.8.0, you can configure the Gateway to log individual API requests. To enable this feature, set the TYK_GW_ACCESSLOGS_ENABLED environment variable to true. You can also configure which fields are logged by configuring the TYK_GW_ANALYTICSLOGS_TEMPLATE environment variable. Below are the available values you can include:

​
Configurable Fields

​
api_key
Obfuscated or hashed API key used in the request.
​
client_ip
IP address of the client making the request.
​
host
Hostname of the request.
​
method
HTTP method used in the request (for example, GET or POST).
​
path
URL path of the request.
​
protocol
Protocol used in the request (for example, HTTP/1.1).
​
remote_addr
Remote address of the client.
​
upstream_addr
Full upstream address, including scheme, host, and path.
​
upstream_latency
Round-trip duration between the gateway sending the request to the upstream service and receiving the response.
​
latency_total
Total time taken to process the request, including upstream latency and additional gateway processing.
​
user_agent
User agent string provided by the client.
​
status
HTTP response status code.

​
Default Template Example

Configuration using tyk.conf
{
    "access_logs": {
        "enabled": true
    }
}
Output: 
time="Jan 29 08:27:09" level=info api_id=b1a41c9a89984ffd7bb7d4e3c6844ded api_key=00000000 api_name=httpbin client_ip="::1" host="localhost:8080" latency_total=62 method=GET org_id=678e6771247d80fd2c435bf3 path=/get prefix=access-log protocol=HTTP/1.1 remote_addr="[::1]:63251" status=200 upstream_addr="http://httpbin.org/get" upstream_latency=61 user_agent=PostmanRuntime/7.43.0

​
Custom Template Example

Configuration using tyk.conf
{
    "access_logs": {
        "enabled": true,
        "template": [
            "api_key",
            "remote_addr",
            "upstream_addr"
        ]
    }
}
Output: 
time="Jan 29 08:27:48" level=info api_id=b1a41c9a89984ffd7bb7d4e3c6844ded api_key=00000000 api_name=httpbin org_id=678e6771247d80fd2c435bf3 prefix=access-log remote_addr="[::1]:63270" upstream_addr="http://httpbin.org/get"

​
Performance Considerations

Enabling access logs introduces some performance overhead:
  • Latency: Increases consistently by approximately 4%–13%, depending on CPU allocation and configuration.
  • Memory Usage: Memory consumption increases by approximately 6%–7%.
  • Allocations: The number of memory allocations increases by approximately 5%–6%.
While the overhead of enabling access logs is noticeable, the impact is relatively modest. These findings suggest the performance trade-off may be acceptable depending on the criticality of logging to your application.

​
track_404_logs

Gateway Only The track_404_logs is a configuration in Tyk Gateway. When you set it to true, the gateway will log all incoming HTTP requests that result in a 404 Not Found error because they don’t match any of your configured API listen paths.
Currently, users can track 404 traffic through the gateway only using this method. Access logs and Tyk Pump’s API traffic logs do not include 404 traffic.

​
Configuration

You can enable this feature by setting the track_404_logs option to true in your tyk.conf file or by setting the TYK_GW_TRACK404LOGS environment variable to true. Example 
time="2023-07-15T10:25:30Z" level=error msg="Not Found" prefix=gateway request="GET /nonexistent/path HTTP/1.1" origin=192.168.1.5:54321

​
Register Custom Log Handlers

Gateway Only Custom logging event handlers can be registered against Gateway events to customise the logs that are generated for those events.

​
Exporting Logs

Gateway Only Tyk Gateway can be configured to send log data to a range of 3rd party tools for aggregation and analysis.
To enable Sentry as a log aggregator, update these settings in both your tyk.conf and your tyk_analytics.conf:
  • use_sentry: Set this to true to enable the Sentry logger, you must specify a Sentry DSN under sentry_code.
  • sentry_code: The Sentry-assigned DSN (a kind of URL endpoint) that Tyk can send log data to.