Basic logging

Basic logging is the first and most primitive form of production visibility: writing text output to stdout, stderr, or a log file so that when something goes wrong you have some re

·Basic application logging exists
·Alerting fires on application errors

·Logs are searchable (centralized logging, not just local files)
·No feedback loop exists between production issues and development priorities

Evidence

·Logging configuration in application code
·Alert configuration (PagerDuty, Opsgenie, or equivalent)

What It Is

Basic logging is the first and most primitive form of production visibility: writing text output to stdout, stderr, or a log file so that when something goes wrong you have some record of what happened. At this level, logging means console.log, print(), System.out.println(), or their equivalents scattered through the codebase wherever a developer thought they might need to debug something. The output is unstructured prose - sentences like "got here", "user id is 42", "something went wrong" - with no consistent format, no severity levels enforced uniformly, and no aggregation layer collecting logs from multiple instances.

Most codebases start here and many stay here longer than they should. The logs exist on individual servers, in container stdout that evaporates when the container restarts, or in files that get rotated and deleted. Retrieving them requires SSH access to the machine, knowledge of which server handled the request, and patience. In a multi-instance or containerized environment, logs from different replicas are siloed - you might find the log for one request on server A and never know that the related error occurred on server B.

For a team not yet using AI agents, basic logging is painful but survivable. Developers debug production issues by SSHing into boxes, grepping log files, and piecing together narratives from scattered output. It is slow and unpleasant but possible. For a team using AI agents, basic logging is a dead end. Agents cannot grep across distributed log files over SSH. They have no queryable interface into production state. When a production incident occurs, an agent has no input channel to investigate it - the logs are inaccessible, unsearchable, and structurally opaque even if retrieved.

The practical ceiling of basic logging is clear: it works for a single developer debugging a single-instance application on a machine they control. The moment you have multiple instances, containers, or multiple developers needing simultaneous access to log data, the approach breaks down. Recognizing basic logging as a maturity floor - something to move past, not optimize - is the first step toward production observability.

Why It Matters

Understanding what basic logging cannot do shapes the upgrade path:

No aggregation means no cross-service correlation - when a request spans three services, basic logging gives you three separate log streams with no way to link them to a single trace
Unstructured output blocks programmatic analysis - you cannot query "all errors from the payment service in the last hour" when the log format is inconsistent prose
Ephemeral storage loses history - container restarts, log rotation, and instance termination destroy the evidence you need for post-incident analysis
No agent input channel - AI agents investigating production issues need a queryable, structured interface; basic logging provides neither queryability nor structure
Debugging requires human presence at the machine - every production investigation requires a developer to manually access infrastructure, which does not scale and cannot be delegated to agents

Getting Started

Audit your current log output - Search for all logging calls in your codebase (console.log, print, logger.info, etc.) and catalog what you have. Most teams discover logs are far more scattered and inconsistent than they realized. This audit becomes the basis for your structured logging migration.
Add consistent severity levels - Even before moving to structured logging, enforce a four-level scheme everywhere: DEBUG, INFO, WARN, ERROR. Replace bare console.log calls with severity-labeled equivalents. This is the minimum prerequisite for any alerting.
Stop writing logs to files; write to stdout - In containerized environments, stdout is the correct log destination. Container orchestrators (Kubernetes, ECS) collect stdout automatically. Writing to files in containers creates the worst of both worlds: ephemeral storage with no collection.
Identify the five most important events in your application - For each service, pick the five things you most need to know about: requests received, errors thrown, external calls made, authentication events, data mutations. Ensure these events are logged at every occurrence before worrying about anything else.
Set up centralized collection immediately - Even with unstructured logs, push them somewhere you can search. A simple ELK stack, Datadog log ingestion, or even Cloudwatch Logs is dramatically better than logs that live only on servers. This single step transforms "logs require SSH" into "logs require a browser tab."
Plan for structured logging as the next step - Basic logging is a known floor. Set a team goal to move to structured JSON logging within one sprint cycle. The upgrade cost is low and the observability payoff is immediate.

Tip

Before refactoring all your logging at once, add a single structured log line at the entry point of every HTTP request: method, path, status code, and duration. This one change gives you HTTP access logs that are queryable and useful, even if everything else remains unstructured.

6 steps to get from here to the next level

Common Pitfalls

Logging sensitive data. Unstructured log output frequently captures request bodies, headers, and parameters that include passwords, tokens, PII, and payment data. When logs are just console.log(request), the full object - including sensitive fields - goes to the log stream. This creates a compliance liability and a security risk. Before centralizing any logs, audit what is actually in them.

Believing that more logging is better. Teams responding to poor observability often add more log statements everywhere, producing high-volume noise that makes the signal harder to find. A production service logging 10,000 lines per second of unstructured prose is harder to debug than one logging 100 lines per second of structured, severity-labeled events. Volume is not visibility.

Treating log files as the archive. Developers who grew up with on-premises servers often treat log files as the permanent record. In containerized, cloud, or auto-scaling environments, log files are destroyed routinely. Any log that is not shipped to a centralized system within seconds of being written should be considered lost.

Not correlating log output to deployment events. At the basic logging level, teams rarely know which deployment caused a change in log patterns. When error rates spike, there is no easy way to answer "did this start after the 2pm deploy?" Tagging logs with deployment version - even as a simple prefix - transforms post-incident investigation from guesswork to fact.

Skipping basic logging entirely and jumping to complex setups. Some teams try to go from no logging to full OTel instrumentation in one step and stall because the scope is too large. Basic logging is a valid intermediate state. Get logs flowing somewhere centralized first, then improve structure incrementally.

Mistakes teams actually make at this stage - and how to avoid them

How Different Roles See It

BobHead of Engineering

Bob's team has production issues that take hours to diagnose because log data is scattered across individual server instances and nobody has consistent access. Post-mortems reference "couldn't find the relevant logs" as a recurring theme. Bob knows the situation is bad but isn't sure how to frame the investment.

What Bob should do: Bob should frame the logging upgrade not as an infrastructure project but as an incident response cost reduction. Track the time spent in the next three production incidents on pure log retrieval and correlation - the time developers spend SSHing into servers, grepping files, and trying to piece together what happened. That time cost, multiplied by developer hourly rate and incident frequency, is the ROI case for centralized structured logging. Bob should approve a two-sprint initiative: sprint one to push all logs to a centralized system (even unstructured), sprint two to move to structured JSON. This is a low-risk, high-return investment that unblocks every future observability improvement.

What Bob should do - role-specific action plan

SarahProductivity Lead

Sarah sees developers spending significant time on production debugging and wants to reduce the friction. She also knows the team plans to introduce AI agents for incident investigation, but the current logging state makes that impossible - agents have no queryable interface to production data.

What Sarah should do: Sarah should treat centralized logging as a prerequisite for any AI agent investment in observability. She should work with the team to instrument one service end-to-end as a reference implementation: structured JSON logs, pushed to a central system, with a dashboard showing error rates. Then document the before/after debugging experience - how long did it take to diagnose the last three incidents with the old approach versus with centralized logs? That concrete comparison is the most persuasive argument for the rest of the team. Sarah should also note that every future observability investment (OTel, alerting, agent investigation) requires this foundation, so the upgrade pays dividends across every subsequent maturity step.

What Sarah should do - role-specific action plan

VictorStaff Engineer - AI Champion

Victor wants to give AI agents access to production signals so they can investigate anomalies autonomously. He knows that the current basic logging setup is the primary blocker - there is no structured, queryable interface for agents to consume.

What Victor should do: Victor should design the logging architecture with agent consumption in mind from the start. This means choosing a log aggregation platform that exposes a query API (Datadog Logs API, Elasticsearch REST API, Loki HTTP API), not just a human-readable UI. The agent's investigation path starts with a query like "show me all ERROR-level logs from the payment service in the 10 minutes before the alert fired" - and that query must be answerable programmatically. Victor should also push for log correlation IDs (trace IDs) as part of the basic logging setup, because without them, even structured logs from multiple services cannot be linked to a single request. The correlation ID is the foundation of distributed tracing, and adding it now costs almost nothing.

What Victor should do - role-specific action plan