What Is Logging in Software? What to Record and Skip

Logging in software is an app writing down what it does as it does it, so that you can work out afterwards what happened. A log entry is a timestamped line: a user signed in, a payment failed, a request took four seconds. When something breaks at 3am, the log is often the only witness.

For apps built with AI, logging matters more than usual. You did not write every line, so you cannot assume you know what the code does at runtime. The log tells you.

Two jobs logging does

The OWASP Logging Cheat Sheet separates two purposes. Security logging records events like failed sign-ins, so you can detect and investigate attacks. Operational logging helps with debugging, performance, and understanding normal behavior. OWASP states that application logging should always be included for security events.

What to record

The OWASP cheat sheet lists events to log where possible:

• Input validation failures and output validation failures

• Authentication successes and failures

• Authorization failures

• Session management failures

• Application errors

• Startup and shutdown events

• Use of higher-risk functions, such as admin actions and access to sensitive data

OWASP is clear that this should be proportionate to risk: there is no one-size-fits-all solution. A small app does not need to log everything, it needs to log the events whose absence would leave you blind.

A useful entry answers four questions: when, where, who, and what. That means a timestamp, an identifier for the part of the app, the user or session involved, and the event type with its severity.

Log levels

Levels let you separate noise from alarms. OWASP gives example scales, including this common set: fatal, error, warning, info, debug, trace.

You can adjust levels, so production might show warnings and above while development shows everything. OWASP says the default should still provide enough detail for business needs, and that logging must never be fully disabled, especially for events required for compliance.

The part that causes breaches: what not to log

Logs are copied, shipped to third-party services, and read by many people. Anything sensitive that enters a log becomes much harder to protect. OWASP says never to log data unless it is legally sanctioned, and lists items that should not be recorded directly, or should be masked, hashed, or encrypted:

• Application source code

• Session identification values (consider replacing with a hashed value if you need to track session events)

• Access tokens

• Authentication passwords

• Database connection strings

• Encryption keys

• Payment card data

Sensitive personal data should be removed or pseudonymized where identity is not needed.

This is where AI-generated code gets risky. Coding agents often add a line that prints a whole request or user object while they debug, and that line can survive into production. Our posts on AI coding agents leaving debug code in production and what agent observability should log cover how to catch it.

Log injection

OWASP defines log injection as untrusted data being included in a log message. Attackers can use it to forge entries or confuse tools that read the logs. Its suggested defenses include using a structured format such as JSON, limiting the size of user-supplied input, and sanitizing carriage return and line feed characters.

Protecting and keeping logs

OWASP advises restricting and periodically reviewing who can read logs, recording access to them, and using TLS when logs travel across untrusted networks. It also says to build in tamper detection and to copy log data to read-only media as soon as possible. On retention, logs should not be destroyed before the required retention period, nor kept beyond it, with legal, regulatory, and contractual obligations shaping the timeframe.

Logging versus error tracking and audit logs

They overlap but differ. Logs are the raw stream. Error tracking groups failures into issues you can triage. An audit log is a protected record of who did what to which data. Most apps eventually want all three. To see where logging fits in the whole build, start from the guide to building an app with AI.

Frequently asked questions

What is logging in software?

It is an application recording events as they happen, such as sign-ins, errors, and slow requests, so that developers can investigate problems later.

What should I never put in a log?

Passwords, access tokens, session identifiers, database connection strings, encryption keys, payment card data, and source code, per the OWASP cheat sheet. Mask or hash anything you need to trace.

Which log level should I use in production?

That depends on your needs, but OWASP says the default should provide enough detail for business needs and that logging should never be fully disabled.

Is logging the same as monitoring?

No. Logging is the record. Monitoring is watching that record, or other signals, to notice problems as they happen.