The (not so) hidden cost of custom logging

If you're a technical leader, there's a good chance your team is spending significant time on custom logging… and you might not even realize how much it's costing you in productivity and incomplete debugging data.

Let's start with a simple test. When a production incident hits, can your team immediately answer these (or similar) questions?

If you're seeing mostly yellow and red on the left side, your team has a custom logging problem. And it's costing you more than you think.

What is custom logging (and why do teams do it)?

Custom logging is when developers manually add code to capture and record information about what's happening in your application. Specifically, the request and response data flowing through your system.

Here's what it looks like in practice:

# Before calling Stripe API
logger.info("Calling Stripe charge API", extra={
    "amount": 1000,
    "currency": "usd",
    "customer_id": "cus_123"
})

# Make the API call
response = stripe.Charge.create(amount=1000, currency="usd")

# After getting the response
logger.info("Stripe response received", extra={
    "charge_id": response.id,
    "status": response.status,
    "response": response.to_dict()
})

Standard observability tools (Datadog, New Relic, Honeycomb, etc.) capture that API calls happened. You can see "POST to Stripe, 200ms, success", but they don't capture what data was in those calls. To understand what actually went wrong during a bug, you need the request and response content: what you sent, what came back, and where it broke.

So teams add custom logging everywhere: in checkout flows, payment processing, email sending, file uploads, database queries. Anywhere they might need to debug later.

The problem: it requires constant manual discipline

Custom logging sounds reasonable in theory. Just add logging when you write the code, right? But here's what actually happens:

"I'll add it later" (never happens)

During a rushed bug fix or feature launch, logging gets deprioritized. "Let's just ship this, we'll add proper logging in the next sprint." The next sprint comes with its own priorities. The logging never gets added.

One-off integrations get skipped

Your team integrates a new third-party service, maybe a document signing API or a geocoding service. The main flow gets logged, but edge cases and error paths don't. Six months later, an issue happens in one of those paths, and there's no data to debug with.

New developers forget

A junior developer ships a new feature. They test it, it works, they move on. Three weeks later, that feature breaks in production. The team scrambles to debug it and realizes: there's no logging. No one can see what data the user submitted or what the external API returned.

Response logging is inconsistent

Even when developers remember to log the request to an external API, they often forget to log the response. Or they log success cases but not errors. Or vice versa. During an incident, you're left guessing what the external service actually returned.

The hidden cost: time and incomplete coverage

Here's what custom logging looks like in practice:

When custom logging coverage is incomplete, here's what happens during incidents:

• Longer debugging time: Engineers spend hours hunting for data that doesn't exist, context-switching between tools, trying to reproduce issues locally.
• Ongoing maintenance burden: Every new feature, every new integration, every new external API requires thinking about logging. It's a tax on velocity.
• Friction in code reviews: "Did you add logging for this?" becomes a frequent review comment that slows down reviews. Teams try to enforce it through checklists and linters, but it's never perfect.
• False confidence: Leadership sees "we have logging" in the observability platform and assumes the team can debug any issue. The reality only becomes clear during incidents when critical data is missing.

How Multiplayer is different

Multiplayer takes a fundamentally different approach: automatic capture instead of manual instrumentation.

Instead of requiring developers to remember to log every API call, Multiplayer automatically captures:

• All internal service requests and responses (full content and headers)
• All external API calls (Stripe, Twilio, AWS, etc.) with full request/response data
• Frontend user actions and network activity
• Everything correlated in one timeline

With Multiplayer:

The session-based difference

The other key difference: Multiplayer uses session-based recording instead of "always-on for all traffic."

Traditional approach (custom logging + observability):

• Collect logs and traces for 100% of traffic (or sample heavily to control costs)
• Store everything forever
• Pay for massive volumes of data you'll never look at
• Still missing the payloads you actually need because you didn’t manually instrument for it

Multiplayer approach:

• Only record sessions where you need visibility (user-reported bugs, errors, specific conditions)
• When you do record, capture everything for that session
• Lower cost because you're not ingesting terabytes of generic logs

This means you get complete data where it matters without the cost of logging everything, everywhere, always.

What this means for technical leaders

If you're responsible for engineering productivity and infrastructure costs, here are the questions to ask:

1. What percentage of our external API calls are actually logged?Ask your team to audit. The answer is usually surprising (and lower than expected).
2. How much time do engineers spend adding logging to new features?This is a hidden tax on velocity. Every feature requires thinking about and implementing logging.
3. During the last 5 incidents, how often did we have all the data we needed?"We had to reproduce it locally" or "we couldn't see what Stripe returned" are red flags.
4. What's our monthly cost for log ingestion and storage?Custom logging creates massive volumes. Even with sampling, the costs add up.
5. How do junior developers learn what to log and where?If the answer is "code reviews catch it" or "tribal knowledge," coverage will stay incomplete.

The bottom line

Custom logging can technically capture everything, but in practice, it rarely does. Coverage degrades over time, external APIs get forgotten, and during incidents, you're left asking "did anyone log this?" instead of debugging.

Automatic capture solves this by ensuring that when an issue happens, you have the complete context (frontend, backend, external APIs, request / response content and headers) already correlated and ready to investigate.

Your team stops spending time on logging instrumentation and starts spending time on what actually matters: understanding and fixing bugs.