What Product Managers Need to Know About Logs & Observability

A product can look perfectly healthy from the outside while something is already going wrong underneath. A payment service may be producing errors, an API may suddenly be responding more slowly or a new release may be affecting only a small percentage of users.

Once software is running in production, teams need ways to understand what the system is actually doing. This is where logs, monitoring and observability become important.

Product Managers don’t need to configure monitoring infrastructure or become experts in tools such as Kibana. What is useful is understanding where Engineering looks when something goes wrong, what different signals can tell you and how technical behaviour connects with the experience users are having.

What are logs?

Software constantly performs actions: users log in, requests reach APIs, payments are processed, background jobs run and systems communicate with each other. Applications can record information about many of these events in logs.

A log entry might tell you that a request arrived at a particular time, which service handled it, whether it succeeded and, if something failed, what type of error occurred.

Conceptually, a log could contain information such as:

10:42:31 — Payment request received — Order 8421 — SUCCESS

or:

10:43:07 — Payment request — Order 8422 — ERROR — Provider timeout

One log entry rarely tells you everything about a product problem, but thousands or millions of them create a detailed record of what the software has been doing.

For Product Managers, logs are useful to understand because they often provide the technical evidence behind statements such as “we’re seeing errors in checkout” or “the problem only seems to affect requests to this service.”

Why should Product Managers understand logs?

Imagine Customer Support reports that some users can’t complete checkout. The product analytics dashboard may show that conversion has fallen, but it probably won’t explain what happened inside the system.

Engineering might then look at the logs and discover that requests to a payment provider are timing out.

The investigation has moved through several layers:

Checkout conversion ↓ → Users reporting failures → Payment errors in logs → External provider timeout

The Product Manager doesn’t need to perform the technical investigation, but understanding what logs are makes it much easier to follow the conversation and connect a product symptom with its possible technical cause.

It also helps when reporting problems. “Checkout doesn’t work” gives Engineering much less to work with than knowing when the issue occurred, which user journey was affected and whether there are identifiers that can help locate the corresponding activity in the logs.

What information can a log contain?

The exact information recorded depends on the application, but logs often contain details such as a timestamp, the service or component involved, the action being performed, the result and information about any error that occurred.

They may also contain identifiers that allow engineers to connect an event with a particular request, transaction or process.

For example:

Timestamp: 10:43:07
Service: Payment Service
Order ID: 8422
Action: Process payment
Result: ERROR
Reason: Provider timeout

Not every system records the same information, and there are important security and privacy considerations around what should and shouldn’t appear in logs. But the basic purpose is consistent: logs leave evidence that can help teams reconstruct what the software was doing at a particular moment.

Log levels

Not every event recorded by an application has the same importance. Teams often use log levels to distinguish routine information from potential problems.

You may encounter levels such as:

• DEBUG — detailed information mainly useful during investigation or development.
• INFO — normal events that describe what the application is doing.
• WARN — something unusual happened, although the system may still be working.
• ERROR — an operation failed or a significant problem occurred.

The exact conventions vary between teams, so an ERROR doesn’t automatically mean the entire product is broken. It may represent one failed operation among millions of successful ones.

This is why context matters. Seeing 100 errors sounds worrying until you know whether they came from 120 requests or 20 million.

What is Kibana?

When applications generate enormous volumes of logs, reading individual files isn’t practical. Tools such as Kibana allow teams to search, filter and explore that information much more efficiently.

An engineer investigating a checkout problem might filter logs by a specific time period, service, error type, order identifier or other available fields. Instead of looking through everything the system produced, they can narrow the search to the activity relevant to the incident.

For example, an investigation might start with:

Time: 14:00–14:15
Service: payment-service
Level: ERROR

and then narrow further when a pattern appears.

Product Managers don’t need to know every Kibana feature or build complex queries. Being able to follow a basic search and understand what the results represent can already make incident and debugging conversations much easier.

Searching and filtering logs

Logs become useful when you can reduce a huge volume of information to the events relevant to the problem you’re investigating.

Suppose a customer reports that an order failed at approximately 15:32. If you know the order ID, Engineering may be able to search for that identifier and follow what happened as the request moved through the system.

A useful report might therefore include:

User: affected customer
Time: approximately 15:32
Order ID: 8421
Action: attempted payment
Observed result: payment failed

That information gives the team several possible ways to find the corresponding technical events.

This is one reason precise bug reports are so valuable. Product and Support don’t need to diagnose the technical cause themselves; they can make the investigation much faster by providing enough context to locate the relevant evidence.

Correlation and request IDs

A single user action may pass through several services before it is completed. Imagine a checkout request moving through:

Frontend → Checkout Service → Order Service → Payment Service → Payment Provider

If every component generates its own logs, investigating the complete journey can become difficult. Teams therefore often use identifiers that allow related events to be connected.

A request ID or correlation ID can travel with the request as it moves through the system. Engineers can then search for that identifier and reconstruct what happened across multiple components.

Conceptually:

Request ABC123

→ Checkout Service
→ Order Service
→ Payment Service
→ External Provider

For Product Managers, the important idea is simply that one user action can generate activity across many systems, and teams need ways to connect those pieces during an investigation.

Logs vs metrics

Logs provide detailed records of individual events, while system metrics summarise behaviour over time.

A log might tell you:

Request 8421 failed at 10:43:07

A metric might tell you:

Payment error rate: 8.4% during the last 10 minutes

Both are useful, but they answer different questions. Metrics are often better at showing that something unusual is happening across the system, while logs can help investigate individual events and understand what actually happened.

A team might first notice an increase in an error-rate metric and then use logs to investigate the failures behind that increase.

This relationship between high-level signals and detailed evidence is central to understanding observability.

What is monitoring?

Monitoring involves continuously tracking selected signals so teams can understand whether a system is behaving within expected limits.

A team might monitor:

• Error rate
• Response time
• CPU or memory usage
• Request volume
• Failed payments
• Application crashes

These signals can be displayed on dashboards and watched over time. The team already knows that these things matter, so it deliberately measures them.

For example, a dashboard might show:

API error rate: 0.3%
Average response time: 220 ms
Payment success rate: 98.7%

If one of those values changes significantly, it can provide an early indication that something needs attention.

Alerts

Teams can’t watch every dashboard continuously, so monitoring systems can generate alerts when certain conditions occur.

For example:

Payment error rate > 5% for 5 minutes → Alert

or:

API response time > 2 seconds → Alert

An alert doesn’t necessarily explain the problem. It tells the team that a predefined condition has been met and that someone may need to investigate.

This distinction matters because an alert is the beginning of an investigation, not the diagnosis itself. “The payment error alert fired” tells you what signal changed; the next question is why.

Monitoring vs observability

Monitoring and observability are closely related, but they aren’t exactly the same thing.

Monitoring focuses heavily on known signals. The team decides in advance that error rate, latency or CPU usage matter and tracks them.

Observability is the broader ability to understand what is happening inside a system by examining the information it produces. It becomes particularly valuable when something unexpected happens and the team doesn’t already have a dashboard designed specifically for that problem.

A useful way to think about the difference is that monitoring helps answer:

“Is something we already know how to measure behaving strangely?”

while observability helps teams investigate:

“Something is wrong. What is actually happening inside the system?”

In practice, the two overlap significantly, and teams may use the terms in slightly different ways.

Logs, metrics and traces

Three types of information commonly appear in observability conversations: logs, metrics and traces.

Logs provide detailed records of individual events. Metrics summarise behaviour numerically over time. Traces help show how a request moves through different parts of a distributed system.

Together, they provide different perspectives on the same product:

LOGS → What happened?
METRICS → How much or how often?
TRACES → Where did the request go?

Imagine checkout suddenly becomes slow. A metric might reveal that response time has doubled. A trace could show that most of the delay occurs when the Payment Service calls an external provider, while logs from that service may contain more detailed information about what happened during those requests.

None of these signals needs to tell the whole story on its own.

What are traces?

Modern applications can involve many services communicating with each other. A trace follows a request as it moves through those components.

Imagine a user submits an order:

Frontend → Checkout → Orders → Payments → Database

The total request takes three seconds, but that alone doesn’t tell us where the time was spent.

A trace might reveal:

Checkout: 100 ms
Orders: 150 ms
Payments: 2,600 ms
Database: 80 ms

Now the team has a much clearer place to investigate.

Product Managers don’t need to configure tracing systems, but understanding what traces represent helps explain how Engineering can investigate performance problems that cross several services.

What is an incident?

An incident is an event that disrupts or degrades the normal operation of a product or system. It could affect everyone or only a subset of users, and the severity can range from a minor degradation to a complete outage of a critical capability.

Examples might include checkout becoming unavailable, login failures increasing dramatically, an API responding extremely slowly or a mobile release causing the application to crash for certain users.

During an incident, the priority is usually to understand the impact, restore service and reduce harm as quickly as possible. Determining the deeper root cause may happen after the immediate problem has been stabilised.

For Product Managers, incidents often require coordination between technical investigation and product impact: What is broken? Who is affected? How severe is it? Is there a workaround? What do customers need to know?

A typical incident flow

Although every organisation handles incidents differently, the general process often follows a recognisable pattern:

Detection → Triage → Investigation → Mitigation → Recovery → Learning

The problem may first be detected through an automated alert, a product metric, Customer Support or even users reporting it directly.

The team then tries to understand the scope and severity before investigating the technical cause. Once enough is known, they may mitigate the issue by disabling a feature, stopping a rollout, rolling back a deployment or using another recovery mechanism.

After the service has recovered, the focus can move from “How do we stop the impact?” to “Why did this happen, and what should we change as a result?”

Product Managers can play an important role throughout this process by helping quantify user impact, prioritise critical journeys and coordinate decisions that affect customers.

Product metrics vs system metrics

Product teams and Engineering teams often look at different types of signals, and both can be necessary to understand what is happening.

A system metric might show:

API error rate ↑

while a product metric shows:

Checkout conversion ↓

The technical metric tells us something has changed in the system. The product metric tells us that the change may be affecting customer behaviour.

Neither one automatically proves that the other caused it, but seeing both move at the same time gives the team a strong reason to investigate the relationship.

This is why observability shouldn’t be treated as completely separate from Product Analytics. Technical behaviour can have direct product consequences, and sometimes the first sign of a technical problem appears in a business or product metric.

Observability isn’t only for incidents

Observability is often associated with outages, but it can also help teams understand normal product behaviour.

Suppose a new feature depends on an external API. After launch, the team may want to know how frequently that API is called, how long it takes to respond, how often requests fail and whether usage is growing as expected.

Those signals can reveal potential constraints before they become incidents.

The same applies after a release. Engineering may monitor technical health while Product watches adoption, conversion or other behavioural metrics. Together, those signals provide a much better picture of whether the release is working as intended.

Observability is therefore useful not only for answering “What broke?”, but also for understanding “How is this capability behaving in the real world?”

Questions Product Managers should ask about observability

You don’t need to decide which monitoring platform the team should use, but you should have a sense of how important product capabilities are observed once they reach production.

For a critical journey, it is useful to know what the team monitors and how quickly a problem would become visible. If checkout starts failing, would an alert fire within minutes, or would the team only discover it when customers begin contacting Support?

You can also ask what information would be available during an investigation. Are there logs for the relevant services? Can requests be traced across systems? Can failures be broken down by platform, version or provider?

Recovery matters too. Once a problem has been detected, who is alerted, who owns the affected system and what options exist to reduce the impact?

These questions aren’t about managing Engineering’s observability setup. They’re about understanding how confidently the organisation can operate the product once it is in users’ hands.

Writing useful bug reports

One practical way Product Managers can help technical investigations is by providing good information when reporting a problem.

Compare:

“Payments aren’t working.”

with:

“Customer 4821 attempted payment at approximately 14:32 CET. The checkout displayed an error after submitting the card. Order ID 8421. Reproduced twice on app version 4.6 on Android.”

The second report doesn’t diagnose the problem, but it gives Engineering multiple ways to start looking for it.

Useful information can include the time the issue occurred, user or account identifiers when appropriate, order or transaction IDs, application version, platform, environment, steps taken and the result the user saw.

You don’t need to know which exact log entry Engineering will need. Your job is to provide enough context for the team to connect the user experience with what happened inside the system.

Do Product Managers need to know Kibana?

Product Managers don’t need to become Kibana experts, and in many organisations they may rarely open it themselves.

However, being comfortable with the basic idea of searching and filtering logs can be surprisingly useful. If an engineer shares a Kibana screen during an incident, you should be able to understand that you’re looking at events produced by the system, filtered according to things such as time, service or error type.

Depending on the team, you may eventually learn to perform a few simple searches yourself. That’s useful, but it isn’t the objective.

The objective is to remove the feeling that production systems are a black box that only Engineering can understand.

Do Product Managers need to understand observability?

You don’t need to configure logging infrastructure, define tracing architecture or build monitoring dashboards. But if you manage a digital product, understanding the basic concepts behind observability makes production behaviour much easier to reason about.

A useful foundation includes knowing the role of logs, log levels, metrics, monitoring, alerts, traces, correlation IDs and incident management, as well as understanding how these technical signals can connect with product metrics.

This becomes particularly valuable when something goes wrong. Instead of treating an incident as simply “an Engineering problem”, you can participate in the parts that belong to Product: understanding impact, identifying affected journeys, helping prioritise recovery and deciding what users need.

The goal isn’t to become an SRE or observability engineer. It’s to understand how teams know what their software is doing once it leaves the development environment and starts serving real users.

Go deeper: Logs, Kibana & Observability for Product Managers

This guide gives you the foundations for understanding how teams investigate and monitor software running in production.

If you want to explore the subject in more depth, Logs, Kibana & Observability for Product Managers covers logs, searches, monitoring, metrics, traces, alerts and incidents specifically from a Product Manager’s perspective, helping you understand what happens behind the scenes when teams investigate production behaviour.

Continue learning Technical Product Management

Observability connects naturally with several other areas of Technical Product Management. Software architecture helps you understand the components producing these signals, APIs explain how many of those systems communicate, Product Metrics show how technical behaviour can affect users, and CI/CD explains how new changes reach production in the first place.

Continue with the Technical Product Management learning path to explore APIs, software architecture, SQL and data, product metrics, security and CI/CD.

Explore the book → Security for Product Managers

Continue learning Technical Product Management

Security is one part of the technical landscape behind modern digital products.

The Technical Product Management learning hub also covers APIs, software architecture, SQL and data, product metrics, logs and observability, and CI/CD and releases.

Explore the Technical Product Management learning hub