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, quietest first: trace, debug, info, warn, error, fatal. 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.