This pull request introduces a configurable logging format to enable RFC3339 compliant timestamps, ensuring more consistent and machine-readable application logs for the Tyk Gateway.

Files Changed Analysis

The changes are centered around the log package, with corresponding updates to configuration and service initialization to adopt the new system:

• log/log.go: Introduces a new Format type with options: text (new default), json, and legacy. The text and json formats use RFC3339 timestamps. A new SetupFormatter function centralizes logger configuration and, critically, configures the global logrus.StandardLogger() to ensure logs from third-party dependencies also adhere to the selected format.
• log/log_test.go: Unit tests are significantly expanded to validate the behavior of SetupFormatter for all new formats, ensuring both the main Tyk logger and the global logrus logger are configured correctly.
• config/config.go: The LogFormat field is updated to use the new logger.Format type, and comments are revised to reflect the new options (text, json, legacy) and the new default (text).
• gateway/server.go: The gateway's startup process is modified to call the new tyklog.SetupFormatter function, replacing the previous direct formatter assignment.
• certs/manager.go: Instances of logrus.New() are replaced with tyklog.Get() to ensure the globally configured logger is used, respecting the application-wide format.
• cli/linter/schema.json: The JSON schema for the linter is updated to include the new log_format enum values: text and legacy.

Architecture & Impact Assessment

• What this PR accomplishes
  The PR allows users to select a log output format via the log_format configuration option. The primary goal is to shift from a legacy timestamp to the widely adopted RFC3339 standard, improving interoperability with external logging systems while maintaining backward compatibility through the legacy option.

• Key technical changes introduced

  • A new log_format configuration option is available in tyk.conf and via the TYK_GW_LOGFORMAT environment variable.
  • The default log timestamp format is now RFC3339 (text format). This is a behavioral change for existing installations that do not have this value set.
  • The new log.SetupFormatter function configures both the main Tyk logger and the global logrus.StandardLogger(). This is a significant architectural improvement that enforces a consistent log format across the entire application and its dependencies.

• Affected system components

  • Logging Subsystem: The log package is directly modified to support multiple formatter types.
  • Gateway Configuration & Startup: The gateway's startup sequence in gateway/server.go is updated to use the new logger setup mechanism.
  • All Gateway Logs: Because the change affects the global logrus logger, any component or third-party library that uses it will now produce logs in the format specified in the Tyk configuration, leading to consistent output across the entire application.

Logging Initialization Flow

graph TD
    A[Gateway Startup] --> B{Read `log_format` from config};
    B --> C["log.SetupFormatter(format)"];
    C --> D{Switch on format};
    D --|text or default|--> E[Create TextFormatter w/ RFC3339];
    D --|json|--> F[Create JSONFormatter w/ RFC3339];
    D --|legacy|--> G[Create TextFormatter w/ legacy timestamp];
    subgraph "Apply Formatter"
        E --> H[Set Tyk logger AND global logrus logger];
        F --> H;
        G --> I[Set ONLY Tyk logger];
    end
    H --> J[Consistent RFC3339 Logs];
    I --> K[Legacy Formatted Logs];

Scope Discovery & Context Expansion

The impact of this change is application-wide. By modifying the global logrus.StandardLogger(), the PR ensures that any module or dependency using the standard logrus instance will now produce logs in the format defined by the Tyk configuration. This is a significant improvement for operational consistency.

The default value for log_format is now "text". This means that existing users who upgrade will see their log timestamp format change unless they explicitly set log_format: "legacy" in their configuration file. This is a minor breaking change for log parsing but a positive step towards standardization that should be highlighted in release notes.

Powered by Visor from Probelabs

Last updated: 2026-05-05T12:58:38.426Z | Triggered by: pr_updated | Commit: f4dde3e

💡 TIP: You can chat with Visor using /visor ask <your question>

✅ Security Check Passed

No security issues found – changes LGTM.

✅ Security Check Passed

No security issues found – changes LGTM.

Architecture Issues (1)

✅ Performance Check Passed

No performance issues found – changes LGTM.

✅ Quality Check Passed

No quality issues found – changes LGTM.

Powered by Visor from Probelabs

Last updated: 2026-05-05T12:58:28.430Z | Triggered by: pr_updated | Commit: f4dde3e

💡 TIP: You can chat with Visor using /visor ask <your question>

HI @shults changes look good but can we adjust the config comments https://github.com/TykTechnologies/tyk/blob/master/config/config.go#L1240 to account for these new options as this is automated for docs? We might also need to update https://github.com/TykTechnologies/tyk/blob/master/cli/linter/schema.json#L965

Hi @MFCaballero. Thank you for your response. It makes sense. Would you mind reviewing the changes?

🚨 Jira Linter Failed

Commit: f4dde3e
Failed at: 2026-05-05 12:57:20 UTC

The Jira linter failed to validate your PR. Please check the error details below:

failed to get Jira issue: failed to fetch Jira issue TT-13727: Issue does not exist or you do not have permission to see it.: request failed. Please analyze the request body for more details. Status code: 404

Next Steps

• Ensure your branch name contains a valid Jira ticket ID (e.g., ABC-123)
• Verify your PR title matches the branch's Jira ticket ID
• Check that the Jira ticket exists and is accessible

This comment will be automatically deleted once the linter passes.

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
81.8% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

/release to release-5.8

/release to release-5.13

⚠️ Cherry-pick encountered conflicts. A draft PR was created: #8178

✅ Cherry-pick successful. A PR was created: #8179