If you’re a Ruby on Rails developer, you might have stumbled upon the frustrating error:
“uninitialized constant ActiveSupport::LoggerThreadSafeLevel::Logger (NameError)”.
This error often pops up after updating dependencies or setting up a new Rails project, leaving developers scratching their heads. But don’t worry—this comprehensive guide will explain why this error happens, how to fix it, and how to prevent it in the future. Written in simple, beginner-friendly language, this article is packed with practical solutions, code snippets, and Ruby on Rails error fixing tips to get your application back on track in 2025.
What Is the “uninitialized constant ActiveSupport::LoggerThreadSafeLevel::Logger” Error?
This error occurs when Ruby cannot find the Logger class within the ActiveSupport::LoggerThreadSafeLevel module, resulting in a NameError. It’s commonly seen in Rails applications or projects using the activesupport gem, especially after a bundle update or when working with tools like CocoaPods or WPScan.
Why Does This Error Happen?
The root cause is often tied to a change in the concurrent-ruby gem, a dependency of activesupport. In version 1.3.5 (released in late 2024), concurrent-ruby removed its dependency on Ruby’s built-in logger library, which activesupport relies on in Rails versions before 7.1. This breaks the expected behavior, causing the Logger constant to be undefined when activesupport tries to use it.
Other common triggers include:
- Outdated Rails versions: Rails 6.1 or 7.0 don’t handle the missing
loggerdependency gracefully. - Ruby version issues: Older Ruby versions (e.g., 2.6, 2.7) or the upcoming Ruby 3.5 (December 2025), where
loggerwill no longer be a core library, can exacerbate this. - Third-party tools: Tools like CocoaPods or WPScan, which rely on
activesupport, hit this error during tasks likepod install.
Let’s dive into the solutions to fix the ActiveSupport Logger error and get your project running smoothly.
Step 1: Understand Your Environment
Before applying fixes, gather information about your setup to choose the best solution:
- Rails Version: Run
rails -vto check your Rails version (e.g., 6.1.7.10, 7.0.8). - Ruby Version: Run
ruby -vto confirm (e.g., 2.6.6, 3.2.5). - Gem Versions: Check your
Gemfile.lockforactivesupportandconcurrent-rubyversions. - Context: Are you running a Rails app, a new project, or a tool like CocoaPods?
This error is common in Rails 6.1, 7.0, or tools using activesupport 6.1.x or 7.0.x with concurrent-ruby 1.3.5 or higher.
Step 2: Quick Fix – Pin concurrent-ruby to Version 1.3.4
The simplest and most reliable solution is to lock the concurrent-ruby gem to version 1.3.4, which still includes the logger dependency.
How to Do It:
- Open Your Gemfile: Find the
Gemfilein your project root. - Add or Update concurrent-ruby:
gem 'concurrent-ruby', '1.3.4'- Run Bundle Install:
bundle install- Restart Your Application: For Rails, run
rails serverorrails consoleto verify the error is gone.
Why It Works:
Version 1.3.4 of concurrent-ruby includes the logger dependency, which prevents the NameError. This is a safe workaround for Rails 6.1 or 7.0 projects that can’t upgrade to Rails 7.1 or 7.2 yet.
When to Use This:
- You’re on Rails 6.1 or 7.0.
- You’re using tools like WPScan or CocoaPods with
activesupport6.1.x or 7.0.x. - You want a quick fix without modifying code.
Step 3: Alternative Fix – Add require ‘logger’
If you can’t or don’t want to pin concurrent-ruby, you can manually require the logger library in your application.
How to Do It:
- Open config/application.rb: This file is in your Rails project’s
configdirectory. - Add require ‘logger’ at the top, before requiring Rails:
require 'logger'
require_relative 'boot'
require 'rails/all'- Save and Restart: Run
rails serverorrails consoleto test.
For Non-Rails Projects (e.g., CocoaPods, WPScan):
If you’re using a tool like CocoaPods, you may need to edit the gem’s source code (not ideal but effective as a temporary fix):
- Locate the
activesupportgem folder (e.g.,/Library/Ruby/Gems/2.6.0/gems/activesupport-6.1.7.10). - Open
lib/active_support/logger_thread_safe_level.rb. - Add
require 'logger'at the top:
# frozen_string_literal: true
require 'active_support/concern'
require 'logger'- Save and retry your command (e.g.,
pod install).
Why It Works:
The Logger class is part of Ruby’s standard library (until Ruby 3.5, December 2025). Explicitly requiring it ensures activesupport can access it, bypassing the missing dependency in concurrent-ruby 1.3.5.
When to Use This:
- You’re using a newer version of
concurrent-ruby(1.3.5+). - You can’t modify the
Gemfile(e.g., in a third-party tool). - You’re preparing for Ruby 3.5, where
loggerwill require explicit inclusion.
Step 4: Upgrade to Rails 7.1 or 7.2
For a long-term solution, upgrade to Rails 7.1 or 7.2, where this issue is fixed. The Rails team addressed the Logger dependency problem in commit 0f5e7a66143.
How to Do It:
- Update Your Gemfile:
gem 'rails', '~> 7.1.0'Or for the latest:
gem 'rails', '~> 7.2.0'- Run Bundle Update:
bundle update rails- Update Dependencies: Check for compatibility issues with other gems and update as needed.
- Test Your Application: Run
rails testor manually test to ensure everything works.
Why It Works:
Rails 7.1 and 7.2 internally handle the logger dependency, making them compatible with concurrent-ruby 1.3.5 and later.
When to Use This:
- You’re maintaining a Rails app and can upgrade.
- You want a future-proof solution.
- You’re not constrained by legacy dependencies.
Note: Upgrading Rails can be complex. Check the Rails Upgrade Guide for detailed steps.
Step 5: Prepare for Ruby 3.5 (December 2025)
Starting with Ruby 3.5 (expected December 2025), the logger library will no longer be part of Ruby’s core library. You’ll need to add it as a gem to avoid future errors.
How to Do It:
- Add logger to Gemfile:
gem 'logger'- Run Bundle Install:
bundle install- Ensure require ‘logger’: Add it to
config/application.rbas shown in Step 3.
Why It Works:
Explicitly including the logger gem ensures compatibility with Ruby 3.5 and beyond, where the standard library no longer provides Logger.
When to Use This:
- You’re planning to upgrade to Ruby 3.5.
- You want to future-proof your application.
Step 6: Fix for CocoaPods or WPScan
If you’re hitting this error during pod install (CocoaPods) or running WPScan, try these specific workarounds:
For CocoaPods:
- Uninstall and Reinstall CocoaPods via Homebrew:
sudo gem uninstall cocoapods
brew install cocoapods- Run pod install with Rosetta (Mac M1/M2):
arch -x86_64 pod install- Pin concurrent-ruby: If you have access to a
Gemfile, add:
gem 'concurrent-ruby', '1.3.4'Then run bundle install and pod install.
For WPScan:
- Downgrade concurrent-ruby:
gem install concurrent-ruby -v 1.3.4Why It Works:
These tools rely on activesupport, which is affected by the same concurrent-ruby issue. Pinning the gem or reinstalling dependencies resolves compatibility problems.
Common Scenarios and Fixes
Here’s a quick reference table for different contexts where this error occurs:
| Scenario | Fix | When to Use |
|---|---|---|
| Rails 6.1 or 7.0 app | Pin concurrent-ruby to 1.3.4 in Gemfile | Quick fix, no code changes |
| New Rails project (7.0.4) | Upgrade to Rails 7.1 or 7.2, or add require 'logger' in application.rb | Long-term solution or new project |
CocoaPods (pod install) | Reinstall via Homebrew or pin concurrent-ruby | iOS development, React Native |
| WPScan | Install concurrent-ruby 1.3.4 globally | Security scanning for WordPress sites |
| Ruby 3.5 (future) | Add gem 'logger' to Gemfile | Preparing for Ruby 3.5 (Dec 2025) |
Debugging Tips for Persistent Issues
If the above fixes don’t work, try these Ruby on Rails error fixing tips:
- Check Gemfile.lock: Ensure no conflicting versions of
activesupportorconcurrent-ruby. - Clear Gem Cache:
gem uninstall concurrent-ruby
bundle install- Use RVM or rbenv: Ensure you’re using the correct Ruby version and gemset.
- Read the Stack Trace: The error trace (e.g.,
logger_thread_safe_level.rb:12) points to the exact line causing the issue. - Update All Gems:
bundle updateBe cautious, as this may introduce other compatibility issues.
Preventing Future Errors
To avoid this and similar errors:
- Lock Gem Versions: Always specify gem versions in your
Gemfileto prevent unexpected updates. - Test After Updates: Run
rails testor manual tests after runningbundle update. - Monitor Ruby 3.5 Changes: Stay updated on Ruby’s standard library changes via Ruby’s official blog.
- Use Dependabot: Enable Dependabot on GitHub to track and test gem updates.
- Join Communities: Follow discussions on Stack Overflow or the Rails GitHub issues for real-time solutions.
FAQs About the ActiveSupport Logger Error
Why does this error only appear after a bundle update?
The bundle update command may have upgraded concurrent-ruby to 1.3.5, which removed the logger dependency, breaking activesupport.
Can I ignore this error?
No, it prevents your application or tool from running correctly. You must resolve it to proceed.
Is upgrading to Rails 7.1 or 7.2 always safe?
Not always. Check your app’s compatibility with gems and test thoroughly before upgrading. Use the Rails Upgrade Guide for help.
What if I’m using an M1/M2 Mac?
Run arch -x86_64 pod install or reinstall CocoaPods via Homebrew to fix architecture-related issues.
Will this error affect Ruby 3.5?
Yes, Ruby 3.5 (December 2025) removes logger from the core library, so you’ll need to add gem 'logger' to your Gemfile.
Conclusion: Get Back to Coding!
The “uninitialized constant ActiveSupport::LoggerThreadSafeLevel::Logger (NameError)” is a common issue in Rails and Ruby-based tools in 2025, but it’s fixable. Whether you pin concurrent-ruby to 1.3.4, add require 'logger', or upgrade to Rails 7.1/7.2, you can resolve it quickly. For future-proofing, prepare for Ruby 3.5 by including the logger gem.
Try these solutions, test your application, and let us know in the comments if you hit any snags. Happy coding!
Resource: For more Ruby on Rails troubleshooting, visit Rails Guides or check out Stack Overflow’s Rails tag.