Where Rails logs live

Something broke, no browser open

A request fails somewhere, with no browser dev tools open and nobody watching. Rails wrote down what happened anyway, in a plain text file. From this project:

tail -n 3 log/development.log

Started GET "/" for ::1 at 2026-08-31 13:22:35 -0300
Processing by Public::PagesController#home as */*
Completed 200 OK in 12ms (Views: 6.9ms | ActiveRecord: 1.8ms (5 queries, 0 cached) | GC: 0.1ms)

Those are real lines from this application's development log.

One file, every request, in order

log/development.log is where this app's development environment writes everything: every request, every SQL query, every rendered template, every exception, appended in the order it happened. Nothing needs a debugger attached or a breakpoint set in advance. The record is already on disk the moment something goes wrong.

Different environments, different files

Each environment logs separately. Development writes to log/development.log. This app's production environment doesn't write a log file at all: it logs to standard output (config.logger = ActiveSupport::TaggedLogging.logger(STDOUT), tagged with each request's id), and the container platform collects that stream. Either way, a busy production log never drowns out a quiet development session.

What this course covers

Lesson 2 breaks down each part of a log line. Lesson 3 follows one request from its first line to its last. Lessons 4 to 6 turn to the other half of the course: reading a Ruby stack trace top to bottom, finding the frame that is this app's code, and knowing which line to read first. Lesson 7 ties both halves together on one triggered failure.

This is the last course in a three-course debugging sequence, after "The scientific debugging method" and "Debugging: binding.irb mastery". Those two investigate a program while it's running. This one reads what already happened, from records the app wrote down.