Why logging matters when you are the only developer on call

If you run an indie app, a side project, or a small SaaS, you probably don’t think about logs until something breaks. Then, at the worst possible moment, you find yourself SSHing into a server, scrolling through a 400 MB text file, and wishing you had a better plan.

Log aggregation is not about collecting more data. It is about making the data you already have easy to search, easy to keep, and cheap to retain. For solo founders and small teams, the goal is to spend the smallest amount of time and money to make logs useful when you actually need them.

This guide walks through the three practical approaches most solo developers land on, the trade-offs between them, and how to pick the one that matches your real query needs, retention requirements, and tolerance for operational overhead.

The three approaches that actually work at small scale

You don’t need an enterprise-grade log platform. Most solo developers end up with one of these three approaches:

  1. Host-level log tailing and file rotation — the default. You tail files, use grep, and rotate logs locally. Free, but fragile once you have more than one server or you need to look back a week.
  2. Simple cloud log shipping — you install a small agent or use your cloud provider’s built-in log pipeline to forward logs to object storage or a queryable cloud service. Cheap, durable, but you trade real-time search for cost.
  3. Managed or self-hosted log services — Loki, Elastic, Datadog, Better Stack, etc. You get fast search, dashboards, and alerts out of the box. You pay in money, configuration, or both.

Each one is a reasonable answer for a specific situation. The trick is matching the approach to your actual pain, not to what looks impressive in a vendor demo.

Start by answering three honest questions

Before you install anything, pressure-test the problem with these questions:

How often do you actually search logs? If the honest answer is “once a month, when a user complains,” you probably don’t need a real-time log platform. File rotation plus a search command may be enough.

How long do you need to keep logs to be useful? Compliance, debugging patterns, and customer disputes all have different retention needs. Non-production environments often don’t need more than a month of retention. Production usually benefits from at least 30 to 90 days of searchable history. Anything older is usually only useful for trend analysis, which a separate, cheaper store can handle.

How many places do your logs live? If everything runs on a single VPS, centralization is not really the problem. If you have a database server, an app server, a worker, and a serverless function or two, the “scattered consoles” problem starts costing you real time during incidents.

These three answers tell you which approach is worth the cost.

Approach 1: Host-level log tailing

This is what you already have. Your app writes to files, you tail them, you grep, and you rotate.

When it is the right choice:

  • You run a single small server or container.
  • You rarely search logs unless something is on fire.
  • Retention beyond a few days is not valuable to you.

What it costs: Nothing in tooling, but it costs you time every time you investigate. Multi-line stack traces, interleaved logs from multiple services, and binary file formats all slow you down. When your service restarts or your disk fills up, you can also lose context exactly when you need it.

How to make it less painful:

  • Use structured logging (JSON) from the start. Plain text logs are hard to filter at scale, while structured logs make grep and jq dramatically more useful.
  • Standardize log levels (DEBUG, INFO, WARN, ERROR, FATAL) so you can filter noise quickly.
  • Add a request ID or correlation ID to every log line so you can follow a single user’s path through your system.
  • Configure log rotation with logrotate or your framework’s built-in tool before disk space becomes a problem.

If this is where you are today, that is fine. Just know the ceiling: the moment you add a second server, or your customer asks “what happened on Tuesday,” you will start shopping for the next approach.

Approach 2: Simple cloud log shipping

This is the most popular step up for solo developers. Instead of keeping logs only on the server, you ship them somewhere durable and queryable.

The pattern looks like this:

  • A lightweight agent or sidecar (Fluent Bit, Vector, Promtail, or your cloud provider’s agent) reads log files or stdout from your app.
  • The agent forwards lines to a destination: object storage (S3, R2, Backblaze), a managed log service, or a self-hosted database.
  • You query logs with simple tools: aws CLI, rclone, a managed log UI, or a hosted query engine.

When it is the right choice:

  • You have two or more servers, or you use any serverless or managed services that produce their own logs.
  • You need weeks or months of retention but don’t need sub-second search.
  • You want logs to survive a server being wiped, restarted, or attacked.

What it costs: Storage is cheap, but watch the egress and request pricing on object storage. Querying logs directly out of S3 is slow without a query layer. The middle-ground option — shipping to a managed log service with a generous free tier — often ends up being the best value at low volume.

How to keep it under control:

  • Decide retention deliberately. Keep hot, searchable logs for 30 days. Move older logs to cold storage or delete them.
  • Filter at the agent. Drop health-check noise, debug logs in production, and known-noisy sources before they leave the server. This is where most of the cost savings come from.
  • Include request IDs and service names in every log line so cross-service queries actually work.

This approach is where many solo developers stay for a long time. It removes the “I lost the logs when the server died” fear without locking you into a heavyweight platform.

Approach 3: Managed or self-hosted log services

This is the category that includes Loki, the ELK stack (Elasticsearch, Logstash, Kibana), Datadog, Better Stack, New Relic, and a long list of others. Some are self-hosted, some are fully managed, and most have free or cheap tiers.

When it is the right choice:

  • You search logs often (daily or during most incidents).
  • You need real-time search across many services.
  • You want dashboards, alerts, and integrations without building them yourself.
  • Your time is worth more than the monthly fee.

The trade-off you should care about: Managed services trade money for time. Self-hosted stacks like ELK or Loki trade setup time and server cost for control. At low volume, managed services with free tiers are usually cheaper than you expect. At high volume, the math flips, and self-hosting starts to look attractive if you already have the operational skill.

Common pitfalls at small scale:

  • Indexing everything. Some managed services charge by data ingested or by indexed volume. Logging every debug line in production will burn through your budget fast.
  • Skipping structured logs. Even the best platform is painful to query if your logs are unstructured text.
  • Forgetting retention defaults. Many services default to keeping logs longer than you need, which quietly inflates cost.

If you go this route, treat log volume and retention as first-class configuration, not afterthoughts.

Retention is a cost decision, not just a storage decision

A common mistake is to keep everything searchable forever. Searchable storage is the expensive kind. Most indie apps do fine with:

  • 7 to 30 days of hot, searchable logs for production.
  • 30 to 90 days of warm logs for incident review and customer disputes.
  • Older logs either deleted or moved to cold storage if you need them for trends or compliance.

Production logs earn their retention. Non-production environments rarely do. Anything outside production usually doesn’t need to be held longer than a month.

This single decision often has more impact on your bill than the choice of platform.

What a sensible starter setup looks like

If you are starting today, a realistic setup for a solo founder is:

  1. Emit structured JSON logs from your app, with a request ID, service name, and log level.
  2. Run a small agent (Fluent Bit, Vector, or your cloud provider’s agent) that ships logs to a destination.
  3. Keep 30 days of searchable logs in a managed service, with a free or near-free tier at your current volume.
  4. Drop known-noisy logs (health checks, debug spam) at the agent, not at the destination.
  5. Add a simple alert on ingestion volume so a sudden log spike doesn’t quietly drain your account.

This setup costs close to nothing at indie scale, survives server restarts, and gives you searchable history when a customer asks “what happened last Tuesday?”

FAQ

Do I need a log platform if I run a single small server? Probably not yet. Host-level tailing with structured logs and good rotation covers most solo cases. The moment you add a second server, serverless functions, or managed services that produce their own logs, centralization starts paying for itself.

Self-hosted or managed — which is cheaper at small scale? Managed services with free tiers are usually cheaper at low volume because you are not paying for a second server or spending your own time maintaining it. Self-hosting becomes more attractive as volume grows or if you already have the operational skill.

How long should I keep logs? 30 days is a reasonable default for production logs at indie scale. Adjust up for compliance or high-value debugging windows, and down for non-production environments. Anything older is usually only useful for trends.

What is the biggest cost trap? Indexing and storing noisy or unnecessary log lines. Filtering at the agent, before logs leave the server, is the highest-leverage cost control you have.

The founder takeaway

Log aggregation is one of those areas where the simplest approach that matches your actual needs wins. Most solo developers do not need a real-time observability platform. They need logs that survive, logs they can search when something breaks, and a cost that stays predictable as the app grows. Match the approach to your real query volume, retention need, and time budget, and revisit it every few months as those numbers change.

Sources