Logs: what they are and why they matter when something breaks
Every request, error and deploy leaves a line somewhere. What the different logs record, how long to keep them, and why an incident without logs is a guess.
The short answer
Logs are the written record of what a system did: which pages were requested by whom, which errors occurred, which functions ran and how long they took, who deployed what, who logged in and from where. Nobody reads them on a normal day. On the day something breaks, they are the only way to know what actually happened rather than guessing. A website without logs, or with logs nobody can reach, turns every incident into speculation. Four kinds matter, they must be kept for a sensible period, and they must not contain what they should not.
The four kinds
| Log | What it records | When you need it |
|---|---|---|
| Access | Every request: time, path, response code, size, source, user agent | Traffic spikes, bot attacks, broken links, what a visitor did before an error |
| Error | Failures in the site or platform, with messages and stack traces | Anything that did not work; the first place to look |
| Application or function | What your own code did: a form received, an email sent, an API called, a payment confirmed | Was the form delivered; did the integration run; why did it fail for one customer |
| Audit | Who changed configuration, access, DNS, deployments, settings | Security incidents, disputed changes, compliance questions |
What good logging looks like
- Exists at every layer: network layer, platform, functions, third-party services with their own logs.
- Is centralised or at least reachable: you know where each log lives and who can open it.
- Is retained for a defined period: weeks for most, longer for audit, configured deliberately.
- Is free of secrets and unnecessary personal data: no passwords, tokens, card numbers or whole form bodies.
- Feeds alerts: error rate rising, unusual traffic, failed logins in volume, a function failing repeatedly.
- Is documented: where to look for what, in the setup document.
Logs and privacy
Access logs contain IP addresses; application logs can contain anything a developer wrote into them. Log what is needed to diagnose problems, mask what is sensitive, set retention, and include log storage in your data map. A log service in another jurisdiction holding your form contents is the same compliance question as a database holding them, and usually a less considered one.
What this means for you
You will never read your website’s logs on a good day, and you will be grateful they exist on a bad one. Make sure all four kinds exist, are reachable, are kept for a defined period, do not contain what they should not, and feed alerts. Then, when something breaks, the answer to “what happened” is a lookup rather than a guess.
Frequently asked questions
Do logs contain personal data?
Access logs contain IP addresses and requested pages, which count as personal data in many jurisdictions. Application logs can accidentally contain far more if a developer logged a whole form submission. Log what is needed to diagnose, mask what is sensitive, keep it for a defined period, and treat log storage with the same care as a database.
How long should we keep logs?
Long enough to investigate an incident you discover late, short enough to respect data minimisation. A few weeks for access and application logs, longer for audit logs of configuration and access changes, and whatever your sector requires. Write the periods down and configure them, rather than keeping everything forever by default.
Who looks at the logs?
Nobody, most days, and that is fine. Logs are read by alerts that watch for patterns, and by a person when something breaks. The mistake is having no logs at all, or logs nobody can reach when the moment comes.