Error Tracking vs Logging vs APM: What Each Tool Does

Three weeks ago I spent four hours debugging an API that returned a 500 error — but only sometimes. The error tracking dashboard showed the exception: NullPointerException at PaymentService.java:247. Cool. I know what broke. But why did it break for this user at this time?

Logs showed the request sequence: user logged in, added items to cart, hit checkout, and then... nothing logged after the checkout initiation. The request just vanished into the void before reaching the payment service.

APM finally cracked it. The trace showed a 31-second database query blocking the connection pool. The payment service never received the request — it timed out waiting for a connection. The exception was a red herring; the root cause was a missing index on the orders table causing a full table scan.

Three tools. Three different answers. Each one was useless without the others.

Quick Verdict: When to Reach for Each

Error tracking when something crashes. You need the stack trace, the exception type, affected users, and enough context to reproduce it. Sentry, Bugsnag, Rollbar — these are the specialists. JustAnalytics bundles error tracking into the broader observability suite.

Logging when you need the timeline. What happened before the crash? What requests hit which services in what order? Structured logs with request IDs let you trace a user's journey through your system. Datadog Logs, Grafana Loki, Logtail, Splunk — dedicated logging platforms. JustAnalytics includes structured logs in Pro. (I've spent embarrassing amounts of time grepping through unstructured logs. Don't recommend it.)

APM when something is slow (or you suspect it's about to be). Where's the latency coming from? Which service is the bottleneck? Which database query is killing performance? Datadog APM, New Relic, Dynatrace — the enterprise players. JustAnalytics covers APM with distributed tracing, P95/P99 latency, and service maps.

Use all three when you're running a production system with real users who will notice when things break. Which is basically every SaaS product, every e-commerce checkout, every API serving paying customers.

Feature-by-Feature Comparison

Aspect	Error Tracking	Logging	APM
Primary question	What crashed?	What happened in sequence?	Why is this slow?
Data type	Exceptions, stack traces, crash reports	Discrete event records with timestamps	Traces, spans, metrics, latency measurements
Typical output	Issue groupings, affected user counts, release tracking	Log streams, searchable event history	Service maps, latency histograms, slow query lists
Investigation flow	Start with exception → find cause → fix code	Start with time range → filter events → reconstruct sequence	Start with slow endpoint → drill into trace → find bottleneck
Best for	Bugs, crashes, runtime exceptions	Debugging business logic, audit trails, understanding user paths	Performance issues, capacity planning, dependency analysis
Alerting	New error types, error rate spikes	Log pattern matches, threshold alerts	Latency breaches, throughput drops, error rate spikes
Retention needs	30-90 days typical (you fix or ignore quickly)	7-30 days typical (storage gets expensive)	7-14 days for traces, longer for aggregates
Typical tools	Sentry, Bugsnag, Rollbar, JustAnalytics	Datadog Logs, Splunk, Grafana Loki, Logtail, JustAnalytics	Datadog APM, New Relic, Dynatrace, Honeycomb, JustAnalytics

The table makes it look clean. In practice, the categories bleed into each other constantly. Sentry added performance monitoring in 2020. Datadog APM includes error tracking. Every logging platform can alert on error patterns. The overlap is intentional — vendors want to consolidate your spend.

What Error Tracking Actually Does (And Doesn't)

Error tracking answers: something broke — what was it?

When your JavaScript throws an unhandled exception, error tracking captures:

The exception type and message
The stack trace (ideally source-mapped back to your original code)
Browser, OS, device info
The user who hit it (if you've identified them)
How many users are affected
Whether this is a new issue or a repeat

The power is in grouping. You don't get 47,000 individual error reports. You get 12 issues, grouped by stack trace fingerprint, sorted by frequency. Issue #1 affects 23,000 users. Issue #12 affects 3. You know where to start.

Good error tracking tools like Sentry also give you breadcrumbs — the last N actions before the crash. Clicked button X, navigated to page Y, made API request Z, then boom. That's incredibly useful for reproduction. We've written about how session replay complements error tracking — seeing the user's screen alongside the stack trace is a game-changer.

But error tracking has blind spots.

It only catches exceptions that actually throw. A silent failure — a function that returns null instead of a result, an API that returns HTTP 200 with {"error": "something went wrong"}, a database write that silently doesn't persist — won't show up in error tracking. The code didn't crash; it just did the wrong thing.

It doesn't show you the full request path. You see where it crashed, but not the sequence of service calls that led there. In a microservices architecture, the exception in Service D might have been caused by bad data from Service B. Error tracking shows you the explosion, not the fuse.

It doesn't measure performance. A request that took 45 seconds but eventually succeeded? Not in error tracking. A database query that's getting slower every day? Not in error tracking. These are APM problems.

We wrote about source map deobfuscation if you want the deep dive on how error tracking turns minified stack traces back into readable code. Short version: without source maps, your "line 1 column 37842" errors are useless.

What Logging Actually Does (And Doesn't)

Logging answers: what happened, in what order?

At its simplest, logging is console.log for production. At its most sophisticated, it's structured JSON events with correlation IDs, severity levels, indexed fields, and queryable retention.

Good logging tells you:

Request came in at 14:32:07.234
User ID 8472 was authenticated
They requested /api/checkout with cart ID abc123
Inventory check passed for items [SKU1, SKU2, SKU3]
Payment service was called with amount $127.40
Payment service responded with transaction ID txn_xyz
Order was created with ID ord_789
Response sent at 14:32:08.102

That's the happy path. When something goes wrong, you have the timeline. You can see that inventory check returned [] instead of the item list, or that the payment service never responded, or that the order creation failed silently.

Sounds obvious, right? You'd be amazed how many production systems I've seen running with logging set to ERROR only. Then something breaks and everyone stands around asking "what happened?" Nobody knows. Nobody logged it.

Structured logging is the key. Instead of:

INFO: User 8472 checked out cart abc123

You want:

{
  "level": "info",
  "message": "checkout_initiated",
  "user_id": 8472,
  "cart_id": "abc123",
  "item_count": 3,
  "total_amount": 127.40,
  "timestamp": "2026-06-19T14:32:07.234Z",
  "request_id": "req_a1b2c3d4"
}

The structured version is queryable. Show me all checkout events where total_amount > 500. Show me all events for request_id = req_a1b2c3d4. Show me error-level events from the payment service in the last hour.

Logging's blind spot is cost. Store everything at DEBUG level and your bill explodes. Store only errors and you lose the context that makes errors debuggable. Finding the right verbosity is an art — and it's different for each service.

Logging also doesn't give you timing relationships. You know Event A happened, then Event B, then Event C. But you don't know that Event B caused the 2-second delay. You have timestamps, but you don't have a trace showing which operation was actually slow.

JustAnalytics includes structured logs in Pro — not as deep as a dedicated logging platform like Splunk, but enough to correlate log entries with errors and traces in one dashboard. The consolidation argument again.

What APM Actually Does (And Doesn't)

APM answers: why is this slow?

Application Performance Monitoring instruments your code to measure timing. Every HTTP request, every database query, every service-to-service call gets timed and recorded. The result is a distributed trace — a tree of spans showing how a single request moved through your system.

A trace might show:

POST /api/checkout took 1,247ms total
→ auth.validate_token took 23ms
→ inventory.check_availability took 89ms
→ db.query SELECT * FROM orders WHERE... took 812ms (!)
→ payment.process took 310ms
→ db.insert INTO orders... took 13ms

That 812ms database query is your problem. Without APM, you'd know the checkout endpoint was slow. With APM, you know exactly which query to optimize.

Good APM tools also show:

P50, P95, P99 latency percentiles (averages lie)
Service maps showing how your services connect
Error rates per endpoint
Throughput and request counts
Slow transaction sampling

OpenTelemetry has become the standard for instrumentation. If your APM tool is OpenTelemetry-native, you can instrument once and switch vendors without re-instrumenting. JustAnalytics is OpenTelemetry-native — the under-5KB script supports distributed tracing out of the box, and you can send OTLP traces from backend services.

APM's blind spot is the why behind the slowness. It tells you the database query took 812ms. It doesn't tell you that the query was slow because the orders table grew from 10K to 10M rows and the index was missing. That requires database-level analysis. APM gets you to the symptom; you still need to diagnose the cause.

APM also struggles with async workflows. A request that kicks off a background job, returns HTTP 200, and then the job fails later? The trace shows the request succeeded. The job failure is a separate trace, and correlating them requires careful request ID propagation.

Honestly, this one bit me hard last year. Perfect traces, zero errors, customer screaming that their webhooks weren't firing. The webhook job was failing 30 seconds after the request completed, in a completely separate trace. Took me two days to figure out what "obviously" should have been a 10-minute fix.

The Overlap Zone: Where Tools Blur Together

Real talk: the lines between these categories have been blurring for years.

Sentry started as pure error tracking. Now it has performance monitoring (traces), session replay, and profiling. Is it APM? Sort of. The tracing isn't as deep as Datadog's, but for many teams it's enough.

Datadog started as infrastructure monitoring, added APM, added logging, added error tracking, added RUM, added session replay. It's the everything platform — with the everything price.

Logging platforms like Splunk and Loki can alert on error patterns, effectively doing error tracking if you structure your logs right. Log {"level": "error", "exception": "NullPointer", "stack": "..."} and you've got error tracking without an error tracking tool.

OpenTelemetry is accelerating this convergence. OTLP (OpenTelemetry Protocol) sends traces, metrics, and logs over the same wire format. Vendors are building around it, which means your instrumentation becomes portable across tools. If you're evaluating OTLP-compatible backends, our OpenTelemetry setup guide covers the integration details.

The question isn't really "which category?" anymore. It's "how many vendors do I want to manage, and how much context do I need correlated?"

My take: the tool category distinctions are mostly marketing now. Pick based on your debugging workflow, not the vendor's product category page.

Three Scenarios Where One Tool Falls Short

Scenario 1: Error tracking alone — the silent failure

Your checkout success rate drops from 98% to 91%. Error tracking shows... nothing new. No new exceptions, no stack traces, no crashes.

Turns out the payment provider started returning 402 Payment Required for expired cards — which your code handled "gracefully" by swallowing the error and returning a generic failure message. No exception thrown, nothing for error tracking to catch.

Logging would have shown the payment API response. You'd search for payment events, see the 402 responses, and know immediately.

Scenario 2: Logging alone — the slow endpoint

Users are complaining that the dashboard loads slowly. You search your logs for /api/dashboard requests and see... normal logs. Request in, request out, no errors.

But you can't see timing without APM. You can't see that the dashboard endpoint calls 7 downstream services and one of them is taking 4 seconds. Logs show what happened; they don't show duration unless you're extremely disciplined about logging start/end timestamps for every operation (most teams aren't).

APM shows the slow span immediately. One look at the trace and you know which service is the bottleneck.

Scenario 3: APM alone — the business logic bug

APM shows all requests are fast and successful. Latency is great, error rate is zero.

But users are seeing wrong data. The checkout total is $0.00 for some users. The order confirmation shows the wrong items.

APM doesn't care about business logic correctness. The database wrote successfully (fast span, no error). It just wrote the wrong value. You need logs showing the inputs and outputs at each step, or you need error tracking with breadcrumbs showing the user's journey. APM sees performance, not correctness.

When Consolidation Makes Sense

Running Sentry + Datadog + Splunk means three vendors, three bills, three sets of credentials, three different UIs to learn.

Worse, it means three different mental contexts. Error happens in Sentry. You find the user ID, open Datadog to look at the trace, realize you need logs, open Splunk, re-enter the time range and user ID, search again.

Context switching kills debugging velocity. We've talked to teams who spend 40% of incident response time just navigating between dashboards. That's not a stat I made up — we actually timed it during onboarding calls. Depressing. For teams running uptime monitoring alongside error tracking, this fragmentation gets even worse.

The consolidation argument is cognitive, not just financial. When your error tracking, logs, APM, and session replay share a session ID natively — when you can click from exception to trace to logs to replay in one UI — debugging happens faster.

JustAnalytics bundles error tracking, APM, structured logs, session replay, and uptime monitoring in one under-5KB script. Pro is $49/mo. That's the consolidation pitch.

But I'll be honest about the trade-off: dedicated tools go deeper. Datadog's APM has features we don't. Splunk's query language for logs is more powerful. Sentry's issue grouping is more mature. If you're at the scale where those marginal features matter, the enterprise tools earn their pricing.

For everyone else? Probably overkill. If you're a SaaS with 50 engineers or fewer, consolidation probably wins. You're not going to use 80% of what Datadog offers anyway — and you'll definitely notice the bill.

(For click fraud detection on paid campaigns, ClickzProtect pairs well with JustAnalytics — correlating ad traffic with downstream errors and performance data. And if you're running pay-per-call, VeloCalls tracks the call leg.)

Frequently Asked Questions

What's the core difference between error tracking, logging, and APM?

Error tracking captures exceptions with stack traces and groups them by root cause — it tells you something broke and where. Logging records discrete events as they happen — requests, state changes, debug output — giving you a timeline. APM measures performance: latency, throughput, service dependencies, slow database queries. They answer different questions. Error tracking: what crashed? Logging: what happened in sequence? APM: why is this slow?

Do I need all three tools or can I pick one?

Depends on your stack complexity. A static marketing site? Logging might be overkill. A microservices architecture with 15 services? You probably need all three. Error tracking without logs leaves you guessing what led to the crash. APM without error tracking shows slow requests but not failed ones. Most production teams running real user traffic benefit from the combination.

Where do these categories overlap?

Modern tools blur the lines constantly. Sentry started as error tracking but now has tracing and performance monitoring. Datadog started as infrastructure monitoring but added logging and error tracking. Some logging pipelines can alert on error patterns. The overlap is real — but the core purpose of each remains distinct. Pick based on your primary question: crashes, sequences, or performance.

Can one platform replace separate error tracking, logging, and APM tools?

Yes. Consolidated observability platforms bundle all three into one bill and one SDK. JustAnalytics does this with error tracking, APM, structured logs, session replay, and uptime in one under-5KB script. Datadog does it at enterprise scale with enterprise pricing. The trade-off is usually depth vs. convenience — a dedicated logging platform like Splunk or Grafana Loki will have more query power than bundled logging in an APM tool.

Try JustAnalytics

All-in-one observability in one under-5KB script: cookieless analytics + error tracking + APM + session replay + uptime + structured logs. Replaces GA4 + Sentry + Datadog + Pingdom + LogRocket. Free tier (100K events/mo), Pro $49/month ($39 annual).

Start free → · AI Command Center MCP