It is 2 a.m., your SaaS is throwing errors, and you do the thing that worked last time: log in and read what the app has been trying to tell you. Except this time the terminal returns almost nothing recent. The last log line was written on a Tuesday three weeks ago. The disk has been full since then, which means your application has been running without a flight recorder for most of a month — and the moment you finally need the recording, you learn it stopped a long time ago. In a very real sense, logging has silently become the outage.
Key Facts
Why Logs Fill Disks Quietly: Logs rarely explode.
The Three Questions That Set Your Retention Policy: Retention is not one number.
Log Rotation and Retention Best Practices: A Starter Policy: Rotation, in plain language: instead of one log file that grows forever, your logging setup periodically splits it into a new file — that is rotation — then compresses the old pieces and deletes pieces older than your retention window.
What to Log in the First Place So Retention Is Cheap: A retention policy is easier to afford when every line earns its space.
This is one of the most common self-inflicted incidents a small SaaS can have, and almost boring in its predictability. Logs are the only thing on a typical server that only ever grows — a few megabytes a day, too slowly to alarm anyone — until the volume fills and everything that writes fails at once: your logger, your background jobs, sometimes your database. Nothing alerted you at 60% or 80%, because gradual growth produces no errors to alert on. The failure arrives at 100%, which is also the day you need your logs most.
The fix is not "buy a bigger disk," and it is not a logging pipeline that takes a weekend to build. It is a retention policy sized to how you actually use logs, plus a rotation mechanism that enforces it automatically. This guide covers the log rotation and retention best practices that matter for a small SaaS: why disks fill quietly, the three questions that set your policy, how rotation works in plain language, a tiered retention table you can adapt, what to log so retention stays cheap, the guardrails that keep a full disk from becoming an incident, and a checklist to close the gaps this week. None of it needs a platform team, and nearly all of it is free.
Why Logs Fill Disks Quietly
Logs rarely explode. They accumulate, and the accumulation has a short list of usual suspects:
- Debug lines left on from development. A per-request timing line, a dump of every query. Harmless while you watched them scroll by; pure sediment once you stopped looking.
- A stack trace on a recurring error. A background job hits a failure and retries forever, writing a twenty-line trace each time. At one retry a minute, that is roughly 29,000 lines a day — over half a million lines of the same trace in a month (illustrative arithmetic, but the shape is common: a single recurring error can out-log everything else you do).
- Access logs multiplied by a crawler. A bot discovering every route — including every API endpoint — can multiply request volume overnight, and every request becomes a line.
- One verbose job. An import, export, or report that logs a line per row processed. Fine at 100 rows; a different story the first time a customer points it at 100,000.
Individually trivial, together they are a steady drip — and a disk moving from 40% to 90% over six weeks generates no errors, triggers no alerts, and changes no customer-visible behavior. Then it crosses 100%, and everything that writes fails at once.
There is a cruel second act. Log lines are writes, so your logging is one of the first casualties of the full disk. The recorder stops working precisely when the incident starts, so the one artifact that would tell you what happened — when it started, how it spread, whether it is getting worse — is the artifact the outage destroyed. And it is rarely just the logs: temp files, sessions, uploads, and on some setups the database share the volume and fail together.
The Three Questions That Set Your Retention Policy
Retention is not one number. It is a small policy per class of log, and three questions answer it.
What do you actually search after an incident?
Be honest about your last few incidents: what did you look for? Almost always it is recent — the hour before the alert, the deploy that preceded it, the first occurrence of the error. In a small SaaS, log data older than a couple of weeks is almost never read again. That makes the last 7 to 14 days your working set: the window that should be easy to search, right on the box. Everything older is archive, and archive should be smaller and cheaper.
What must you keep for business or legal reasons?
Some records are not debugging data at all: billing events, authentication records, permission changes, evidence for a customer dispute. These belong in a durable, queryable store — a database table or an append-only audit trail — not in a rotating file that will be compressed and deleted on schedule. How long to keep them depends on your jurisdiction, your industry, and the contracts you sign, and those obligations vary; check what actually applies to you rather than copying a number from a blog post, including this one. What does not vary is the storage principle: records with a compliance flavor should not share a lifespan with access logs.
What can go immediately?
Debug noise: SQL dumps, payload bodies, verbose timing lines, the per-row chatter of batch jobs. It has the shortest useful life (often zero), the largest volume, and the worst risk-to-benefit ratio, because verbose logging is where secrets leak. Default it off in production, or give it a 48-hour lifespan at most. Deleting debug noise aggressively is not a loss; it is the policy working.
Log Rotation and Retention Best Practices: A Starter Policy
Rotation, in plain language: instead of one log file that grows forever, your logging setup periodically splits it into a new file — that is rotation — then compresses the old pieces and deletes pieces older than your retention window. Three knobs control everything:
- When to split: by size (a new file every 50 MB) or by time (a new file every day). Time-based splitting makes "the logs from the 14th" trivially findable; size-based splitting bounds the worst case when a chatty error goes wild.
- What happens to old files: usually compression, which typically shrinks plain-text logs by 80–90% or more.
- When files are deleted: after N rotations or N days. This is your retention, enforced automatically instead of by memory and good intentions.
Tool-wise this is commodity plumbing: your framework or platform likely has a built-in option, and most deployment platforms expose log settings without you touching the OS at all. On your own server, the standard rotation tooling does it in a few lines. Exact syntax varies by tool, so treat the following as a fictional sketch of the shape, and check your own docs:
# FICTIONAL EXAMPLE — an illustration of the shape, not a working config/var/log/myapp/*.log { daily rotate 14 compress missingok notifempty}
Fourteen daily files, compressed, then deleted — that is "two weeks of searchable history" expressed as four lines of plumbing.
With the mechanism set, the policy is where judgment lives. Here is a tiered starting point you can adapt:
Log class
Keep for
Where it lives
App errors and warnings
30–90 days; compressed after the first week
Instance log directory, rotated daily
Access logs
7–14 days
Instance, rotated daily, deleted on expiry
Debug-level output
48 hours, or off
Ephemeral — first candidate to disable
Audit events: billing, auth, permission changes
Years, per your obligations
Database table or off-box archive, not a rotating file
Deploy and build logs
Whatever your platform retains
The platform's dashboard
Two caveats on that table. First, the durations are a starting point, not a rule — adjust them to your obligations and to how often you actually go digging. Second, the last two rows break the pattern on purpose: audit events should not live on a disk-bound file at all, and deploy logs may not be your disk's problem if your platform keeps them. Tiering works because each class gets the cheapest storage that still serves its purpose.
What to Log in the First Place So Retention Is Cheap
A retention policy is easier to afford when every line earns its space.
Write structured, single-line events. One line per event, with consistent fields — timestamp, level, request ID, event name, the two or three details that matter. Single-line events are searchable with nothing more exotic than grep, and they compress better. Stack traces are the accepted exception; keep the event itself on one line.
Put a request ID in everything. When a customer reports a failure, the ID turns "search two weeks of logs" into "search two weeks of logs for one string" — the difference between five minutes and an hour. It also follows one request across your web app, background jobs, and services, so a short retention window still covers a lot of ground.
Use log levels honestly. The levels only work as a retention tool if they mean something:
Level
What it should mean
Production posture
Error
Something is broken and a human should look
Always kept, alerts attached
Warn
Suspicious or degraded; worth watching as a trend
Kept for your full hot window
Info
Business-significant events: signup, payment, job finished
Kept, but curated — not a dumping ground
Debug
Forensic detail for hunting one specific problem
Off by default; flip on briefly
If your "info" stream is full of dump lines, you will need months of retention to find anything, which is exactly backwards. Curation now buys a shorter, cheaper window later.
Never log secrets — make redaction a habit. No tokens, passwords, session identifiers, full card numbers, or personal data you would not want in a file that lives for months and gets copied into backups. Retention multiplies whatever you log, including mistakes: a token written to a log once and kept 90 days is a 90-day exposure, replicated into every compressed archive and off-box copy you make afterward. Scrub at the source — redact inside the logging call itself, not in a cleanup script you will forget to run.
Disk-Full Guardrails
Rotation plus tiers is the main defense. Three more guardrails make the failure mode structurally hard to reach:
Cap the log directories. Rotation with a fixed number of files puts a hard ceiling on what logs can consume. Know that ceiling, and make sure it fits inside the volume with room for everything else that writes. A log directory that can grow without bound is not a logging setup; it is a countdown.
Alert at 70–80% disk. This is the cheapest alert you will ever configure and the one most likely to save you a weekend: a disk alert fires on a Tuesday afternoon, when the fix is a ten-minute ticket, while the same disk discovered at 100% on a Saturday is an incident with customers watching. Put it on every volume that writes logs, temp files, or uploads — not just the one you remember about.
Ship the important logs off-box. Copy errors, warnings, and audit events somewhere that is not the instance: another machine, an object store, a log service. Two reasons. First, a dead instance should not take its history with it — a machine that cannot boot cannot tell you why. Second, off-box copies are immune to the disk-full event itself, which destroys on-box logging at exactly the wrong moment. You do not need to ship everything; a nightly copy of the valuable 5% beats shipping nothing by an order of magnitude.
What Searchable Logs Are Worth at 3 A.M.
Run the comparison honestly. Incident with seven days of searchable logs: the alert fires, you pull the customer's request ID, you find the first occurrence of the error, you see what changed right before it — and twenty minutes in, you have a fix, a rollback, or at least an accurate status-page sentence. Incident without them: the recorder stopped weeks ago, so you restart the service and hope, you write "still investigating" four times, and you never learn whether this was the first occurrence or the two-hundredth.
Searchability is also what turns incidents into improvements. "Has this error happened before?" is the question that separates a one-off from a trend, and only retained logs answer it. For a solo founder, diagnosis time is the dominant share of incident duration — you are the on-call engineer, the deploy pipeline, and the status page. Logs that shorten diagnosis are not a nicety; they are the mechanism that turns a 3 a.m. page into a 20-minute fix instead of a four-hour fog.
A Walkthrough: From Disk-Full to a Fifteen-Minute Fix (Illustrative)
Consider a fictional but typical sequence. A founder running a small project-management tool inherits an incident: monitoring says the app is healthy, but customers cannot upload attachments. Logging in, she finds the disk at 100% — and the application logs stopped three weeks earlier. A background sync job had failed and begun retrying every minute, each retry writing a stack trace, until the logs alone consumed the disk. The failed uploads were the visible casualty, not the cause.
Recovery takes two hours: clear the offender, rotate or truncate the runaway log (never delete a file a running process still holds open), confirm writes resume. Then comes a Saturday afternoon of prevention: daily rotation with two weeks retained, errors compressed and kept for 60 days, debug logging disabled, audit events — signups, permission changes, billing — moved into a database table, a disk alert at 75%, and a nightly copy of errors to object storage.
Six weeks later, a customer reports failed imports. She greps the request ID from the report, finds the first occurrence in the compressed error logs from four days ago, and sees it started two minutes after a deploy — a parsing change the new release introduced. Rollback, verify, done: roughly fifteen minutes, with the evidence coming from files that would once have been deleted or filled the disk. The sequence is illustrative, but every step in it is ordinary plumbing you can set up in an afternoon.
Where Deployxa Fits — and Where It Doesn't
If you deploy on a platform, part of the log story is handled for you. On Deployxa, logs are visible per deployment from the dashboard: the history of what each release did — build output and deploy-time behavior — is retained by the platform rather than living on one instance where it fills a disk or dies with the machine. When the question is "what changed in the deploy right before this error," that history is already there.
The honest limits: your application's own log files on your instances are still your disk to manage. Rotation schedules, retention tiers, redaction, disk alerts, and off-box shipping of application errors and audit events all remain the owner's job, on Deployxa as anywhere else. Long-term archival and external log shipping are likewise yours to arrange — the platform keeps deploy-related history visible, but it does not replace your retention policy. The docs cover what the platform records, and the product suite outlines the deployment workflows this sits alongside. Decide your tiers first, then check what the platform already covers.
Your Log Retention Checklist
- Every log directory rotates: splits by size or time, compresses old files, deletes by age
- Retention is tiered by log class — errors, access, debug, audit — not one global number
- Debug-level logging is off in production by default, with a switch to flip it briefly
- Total log-directory size is capped at a number you can state out loud
- Disk alerts fire at 70–80% on every volume that writes logs, temp files, or uploads
- Errors and audit events are shipped off-box nightly
- A request ID ties together every log line for a single request
- No secrets, tokens, session IDs, or full card data in any log line — redaction happens at the logging call
- Billing, auth, and permission events live in a durable table or audit trail, not a rotating file
- You know what deploy and build history your platform retains, and where to see it
Rehearse the Change Before You Need It
Pick one evening this week and run the drill on a staging copy first: apply rotation and your tiered retention there, let a day of logs flow through it, confirm old files compress and expire on schedule, and simulate a filling volume to watch the alert fire. Once the config proves itself on staging, ship the same setup to production, then check the real numbers — disk percentage, oldest surviving log line — and write them down somewhere boring. While you are at it, open your deployment dashboard and see how much of the history problem a platform is already holding for you. That hour of rehearsal buys the thing this whole article is really about: an incident where the logs are there, the disk is not full, and the fix takes twenty minutes.