Log levels

Log levels signal operational urgency: debug for development detail, info for normal lifecycle events, warn for recoverable anomalies, error for failures that need attention. Levels should reflect **actionability**, not developer mood.

| Level | Typical use | |-------|-------------| | debug | Verbose internals; often off in production | | info | Request handled, job completed, deploy finished | | warn | Retries, deprecations, slow dependencies | | error | Failed request, uncaught exception, data loss risk |

					if (attempt > 1) logger.warn({ attempt, provider: 'stripe' }, 'payment retry');
logger.error({ err, orderId }, 'payment failed after retries');
				

Tune production defaults: info or warn baseline, debug enabled temporarily per service during investigations. Avoid logging every successful loop iteration at error "so dashboards see it."

On interviews: default levels per environment, sampling vs full debug, and how log level choices affect alert noise.

Common pitfalls: everything logged as error; debug left on under load; warn used for expected business cases (e.g. 404 on user typo).

The trade-off is signal clarity versus log volume and cost.

Checklist:

• Map levels to operator response expectations.
• Keep production defaults lean.
• Use structured context on warn/error.
• Gate debug behind flags or dynamic config.