When software misbehaves, the first piece of advice is usually "check the logs". A log file is the program's diary: a plain-text record, written line by line as events happen. Learning to read one turns a vague failure into a specific message.
What a log file is
A log file, usually with a .log or .txt extension, collects entries that a program, service or operating system writes as it runs. Each entry records an event: a user signed in, a request failed, a disk filled up, a setting was loaded. Because entries are appended in order, the file reads as a timeline.
There is no single log format. Programs choose their own, but most entries contain some combination of:
- A timestamp
- A severity level, such as INFO, WARN or ERROR; see log levels explained
- A source, such as the component, module or process
- A message describing what happened
- Sometimes a request ID, user or thread to connect related lines
For example:
2026-10-02 14:31:07,412 ERROR [db] Connection refused: localhost:5432
2026-10-02 14:31:07,415 WARN [retry] Attempt 2 of 5 in 3s
Common formats
- Plain text lines like the above, written for people to read
- Structured logs, where each line is JSON, which are easy for tools to filter. These are often JSON Lines, one object per line.
- Access logs from web servers, with a fixed layout of client address, time, request, status code and size
- System logs from the operating system, which on some systems are stored in binary form and read with special tools
Where to find them
- Applications: a
logsfolder next to the program, or a path set in its settings - Windows: Event Viewer holds system and application logs; many programs write
.logfiles to the AppData or ProgramData folders - macOS: the Console app, and
~/Library/Logs - Linux:
/var/logfor system and service logs, andjournalctlfor services managed by systemd - Mobile: developer tools or in-app "export logs" options; Android logging is read through developer tools such as
logcat
How to read a log
- Start at the time of the problem. Find the timestamp when it went wrong and read around it.
- Look for the first error, not the last. Later errors are often consequences of an earlier failure.
- Read the lines before the error. The context often explains the cause.
- Search by level, for ERROR and FATAL, or by an ID shared across related lines.
- Note repeated patterns. The same message every few seconds suggests a retry loop or a scheduled task.
- Check time zones. Timestamps may be in UTC while your clock is local.
For stack traces, which are multi-line entries listing the chain of calls leading to an error, the cause is usually at the top or bottom of the trace depending on the language, with the message of the exception on the first line.
Opening a log file
A .log file is plain text, so any editor works. Docento's Text & Markdown Editor opens .log files locally in the browser in a fixed-width font, with a Find box that steps through matches. Files over 5 MB are too large for it. See how to open large log files and how to search log files.
A word on privacy
Logs can contain personal data, tokens, IP addresses and file paths. Before sharing one for support, scan it for sensitive values and remove them. Because Docento's editor works on your device, the file is not uploaded when you open it.
Keeping logs manageable
Programs usually rotate logs: when a file reaches a size or age limit it is renamed (for example app.log.1) and a new one starts, and old ones may be compressed or deleted. If the entry you need is missing, look for the rotated files.
Takeaway
A log file is a timestamped text record of what a program did. Read from the time of the problem, find the first error rather than the last, and use search to cut through the noise.
