How to Disable HTTP Request Logs in Medusa v1 and v2

Excessive HTTP request logs in Medusa.js can slow down your e-commerce backend and clutter production logs. While detailed request logging is valuable in development, it becomes a performance bottleneck in live environments with high traffic. In this guide, you’ll learn how to disable or manage request logs in Medusa.js v1 and v2, improve server efficiency, and keep only the essential logs that truly matter in production.

Why Control HTTP Request Logs?

HTTP request logs in Medusa.js can become overwhelming, especially for e-commerce stores with significant traffic. Every API call, webhook, and admin request generates log entries. While useful for debugging, these logs can:

• Degrade performance - Writing thousands of log entries consumes CPU and I/O resources
• Reduce log readability - Important error messages get buried in routine request logs
• Increase storage costs - Log aggregation services charge based on volume
• Complicate monitoring - Alert systems struggle to identify real issues among noise

For production stores handling hundreds or thousands of requests per minute, controlling request logs is not just a convenience—it's a necessity.

Disabling Request Logs in Medusa.js v1

Medusa v1 doesn't provide a built-in configuration option to disable HTTP request logs. While Medusa has moved to v2 and only provides security updates for v1, many production stores still run on v1. The lack of log control can be a significant operational challenge.

The only reliable solution is to patch the Medusa source code using patch-package. This approach modifies how Medusa's HTTP logger behaves, allowing you to conditionally disable request logs based on the LOG_LEVEL environment variable.

Prerequisites

• A Medusa v1 project
• Node.js and npm/yarn installed
• Access to modify your project's dependencies

Step 1: Install patch-package

First, install patch-package as a development dependency:

npm install --save-dev patch-package

Or with yarn:

yarn add -D patch-package

Step 2: Add postinstall Script

Update your package.json to run patch-package after installing dependencies:

{
  "scripts": {
    "postinstall": "patch-package"
  }
}

This ensures your patches are applied automatically whenever you run npm install or yarn install.

Step 3: Locate the HTTP Logger File

Navigate to your node_modules directory and find the Medusa core HTTP logger:

node_modules/@medusajs/medusa/dist/loaders/logger.js

This file initializes the Morgan HTTP request logger that generates all the request logs.

Step 4: Modify the Logger Configuration

Open node_modules/@medusajs/medusa/dist/loaders/express.js and locate the Morgan middleware configuration. It typically looks like this:

skip: function () { return process.env.NODE_ENV === "test"; },

Replace it with a conditional configuration:

skip: function () { 
	return process.env.LOG_LEVEL !== "debug" || process.env.NODE_ENV === "test"; 
},

This modification ensures that HTTP request logs appear when LOG_LEVEL=debug is explicitly set.

Step 5: Create the Patch

After modifying the file, create a patch:

npx patch-package @medusajs/medusa

This command generates a patch file in patches/@medusajs+medusa+[version].patch that contains your modifications.

Step 6: Configure Your Environment

In your production environment, ensure LOG_LEVEL is not set to debug

Verification

Restart your Medusa server. In production mode, you should no longer see HTTP request logs like:

[http]: GET /store/products 200 45ms
[http]: POST /store/cart 201 120ms

These logs will only appear when running with LOG_LEVEL=debug.

Note that LOG_LEVEL cannot be set using .env file, because this environment variable must be set before starting the server, as a system environment.

Disabling Request Logs in Medusa.js v2

Good news! Medusa v2 includes built-in support for controlling HTTP request logs without requiring patches. The logging system has been completely redesigned with proper configuration options.

Using the Logging Configuration

Medusa v2 provides a comprehensive logging configuration system documented in the official Medusa v2 logging guide.

The available log levels, from lowest to highest levels, are:

1. silly
2. debug
3. verbose
4. http (default, meaning only HTTP requests are logged)
5. info
6. warn
7. error

You can change that by setting the LOG_LEVEL environment variable to the minimum level you want to be logged. If you want to disable HTTP request logs specify your own LOG_LEVEL env variable without http.

Best Practices

Regardless of which Medusa version you're using, follow these logging best practices:

1. Use Environment-Specific Configurations

Always differentiate between development, staging, and production logging:

• Development: Enable all logs including HTTP requests
• Staging: Enable moderate logging to catch issues
• Production: Disable HTTP logs, keep error and warning logs

2. Monitor Performance Impact

Before and after implementing log controls, monitor:

• CPU usage during peak traffic
• I/O wait times
• Log storage consumption
• Application response times

3. Keep Critical Logs

Even when disabling HTTP logs, maintain:

• Error logs (always enabled)
• Warning logs (business logic issues)
• Security-related logs (authentication failures, suspicious activity)
• Transaction logs (payment processing, order creation)

4. Implement Log Rotation

Troubleshooting

Patch Not Applied (v1)

If your patch isn't working:

1. Verify postinstall script is in package.json
2. Delete node_modules and reinstall: rm -rf node_modules && npm install
3. Check patch file exists: ls patches/
4. Manually apply: npx patch-package @medusajs/medusa

Logs Still Appearing (v2)

If logs persist in Medusa v2:

1. Check environment variables are loaded: echo $LOG_LEVEL
2. Check for custom middleware that might add logging

Conclusion

Controlling request logs is crucial for high-traffic Medusa.js e-commerce stores. While Medusa v1 requires a workaround using patch-package, Medusa v2 provides built-in configuration options that make log management straightforward.

For v1 projects, the patch approach is currently the only reliable solution, despite v1 being in maintenance mode with security-only updates. Many production stores still depend on v1, making this patch an essential operational improvement.

For new projects or those planning to migrate, Medusa v2 offers a more robust and maintainable logging system that eliminates the need for patches.

By implementing proper log control, you'll improve application performance, reduce operational costs, and make your logs more actionable for debugging real issues. Whether you're on v1 or v2, taking control of your logging strategy is an investment that pays dividends in operational efficiency.