Log level
The severity tag on a log line (debug, info, warn, error) and the dial that decides which of them actually get written.
See it
What it is
A log level is a severity tag on each line plus a threshold that decides which lines survive. The usual ladder, least severe first: trace, debug, info, warn, error, fatal. The threshold runs the other way round, so trace is the most verbose setting and fatal is the quietest one. Set the threshold to info and every debug and trace call becomes a no-op, which is how one codebase serves both a chatty local machine and a calm production box. The idea is inherited from syslog severities, which is why you sometimes see 'notice' and 'critical' in older systems.
Wire the threshold to a LOG_LEVEL environment variable so you can turn verbosity up on a misbehaving instance without a code change. A workable convention: debug for values you would have printed while writing the code, info for business events worth counting, warn for something degraded but handled, error for anything a human should look at, fatal for the process is going down now.
Gotcha: level inflation destroys alerting. If expected outcomes (a 404, a failed login, a retried request) get logged at error, your error rate becomes noise and people stop reading the alerts. The second trap is cost: a debug call that stringifies a huge object still pays for that serialization even when debug is off, so guard expensive payloads behind a level check or pass them lazily as fields.
Ask AI for it
Add leveled logging to this app. Read LOG_LEVEL from the environment, defaulting to debug in development and info in production, and validate it against trace/debug/info/warn/error/fatal at startup. Re-tag existing log calls to that convention: debug for developer detail, info for business events, warn for handled degradation, error only for things a human must act on, and never error for expected 4xx responses. Wrap any log call that serializes a large object in a level check so the payload is not built when the level is disabled.