Everyone debugging serverless starts in the same place: the CloudWatch console. It's free, it's already there, and for a quick look it's fine. The pain shows up when something's actually broken — when you're trying to find one failing invocation among hundreds of concurrent executions, scattered across log streams, interleaved by timestamp. This page compares reading Lambda logs in the CloudWatch console with doing it in LogStitch — honestly, including the times you should just stay in the console.
First, the important disclaimer: LogStitch is not a replacement for CloudWatch. Your functions still write to CloudWatch Logs; your alarms, metrics, and dashboards still live in CloudWatch. LogStitch is a read client — it fetches those logs with your IAM credentials and gives you a better surface to read and debug them on. Think of it as replacing the console log viewer, not the service.
At a glance
Reading Lambda logs, side by side. This compares the CloudWatch console experience with LogStitch — not CloudWatch's storage, alarms, or metrics, which LogStitch doesn't touch.
| Reading Lambda logs | CloudWatch console | LogStitch |
|---|---|---|
| Platform | Any browser, any OS, phone | Native macOS only (26.1+) |
| Setup | None — logs are already there | Install app, add an AWS profile (14-day trial) |
| Cost to read logs | Free (you pay ingest/storage regardless) | One-time $49 / $99 |
| Unit you read | Log streams (per execution environment) | Invocations (per request ID) |
| Concurrent invocations | Scattered across streams / interleaved | Separated — one invocation at a time |
| Group logs by request ID | Manual — filter on the request ID | Automatic |
| One request across functions | No — open each log group in turn | Stitched (correlation ID / X-Ray / temporal) |
| Structured-JSON log lines | Raw text | Parsed tree, per-field copy, level badges |
| Error-pattern clustering | No | Yes — templated + impact-ranked |
| Anomaly detection | Separate setup (alarms / anomaly detection) | Built in — z-score on errors, duration, cold starts, cost |
| History past retention | No — expires per policy | Yes — local SQLite keeps it |
| Offline access | No | Yes |
| Live tail | Yes — billed $0.01/min* | Yes — included |
| Alarms, metrics, dashboards | Yes — full CloudWatch | Out of scope — reads logs |
| Non-Lambda logs (ECS, API GW, VPC…) | Yes | Lambda-focused |
| MCP / AI integration | No | Built-in MCP server for Claude |
| Best for | Occasional reads; the whole AWS platform | Daily Lambda debugging |
* CloudWatch Live Tail is billed at $0.01 per minute of streaming in commercial regions. Browsing existing log streams in the console has no per-read charge — you pay for ingestion and storage regardless of which tool reads the logs. See the official AWS CloudWatch pricing page for your region.
Where the CloudWatch console wins
A comparison that only lists the incumbent's weaknesses isn't honest. Here's where the console is the right tool — and it genuinely is, often.
1. It's free and already there
There is nothing to install, nothing to buy, and nothing to configure. The moment your Lambda runs, its logs are in CloudWatch and you can read them. You're already paying for ingestion and storage, so reading them in the console costs you $0 more. For a quick check or an occasional look, that's unbeatable.
2. Any device, any OS — including your phone
On-call at 3am from your phone? Borrowed a Windows laptop? The console is a URL. LogStitch is a macOS app (26.1+), so if you're not at a Mac, it's not an option and the console is exactly what you want.
3. It's the whole platform, not just logs
CloudWatch is alarms, metrics, dashboards, subscription filters, and logs from every service — ECS, API Gateway, VPC flow logs, RDS, your own EC2 apps. LogStitch reads Lambda logs and nothing else. If your debugging spans more than Lambda, or you need alarms and metrics in the same place, that's CloudWatch's job, not LogStitch's.
4. Team access and sharing are built in
Everyone with the right IAM role already has the console. You can copy a deep link to a log group and time range and paste it in Slack, and a teammate sees the same view. LogStitch is a single-user local app; it has no shared team workspace.
Where LogStitch wins for Lambda debugging
The console is a general-purpose log viewer for all of AWS. LogStitch assumes one thing — that you're debugging Lambda — and builds everything around it. That focus is where the time savings come from.
1. Invocations, not log streams
CloudWatch organizes Lambda logs by log stream — one per execution environment (container), not one per request. A single stream holds many sequential invocations, and concurrent invocations land in different streams. So the merged view interleaves executions by timestamp, and reading one request means filtering on its request ID and stitching the lines back together yourself. LogStitch reads the request ID stamped on every line and groups the logs into invocations automatically — one execution, in order, as a single unit you can actually read.
2. One request, across every function it touched
A serverless request usually spans several functions. In the console that means opening each function's log group in turn, filtering on the request or correlation ID in each, and interleaving the results by hand. LogStitch stitches the invocations from all the functions a single request passed through into one ordered timeline, with end-to-end duration. It matches them by a correlation ID you log in structured JSON, an AWS X-Ray trace ID, or temporal proximity.
Cross-function stitching works within a single AWS account and region. Cross-account and cross-region correlation are not supported.
3. Structured log lines, not raw text
The console shows log lines as raw text — a structured JSON log or error arrives as a single wrapped blob, and the START/END/REPORT boilerplate sits inline. LogStitch parses each line: it pretty-prints JSON as a syntax-highlighted tree with per-field copy, badges each line by level (ERROR/INFO/DEBUG), stamps a relative offset from the start of the invocation, and folds the REPORT line into structured stats — duration, billed duration, max memory, cold-start. A raw view is one toggle away when you want it.
4. Error patterns and anomalies, surfaced for you
LogStitch clusters similar errors by generalizing them into templates (stripping UUIDs, timestamps, IDs, and numbers) so recurring failures collapse into one ranked pattern with a count, and it flags z-score deviations on error rate, P95 duration, cold-start rate, and cost against each function's own 7-day baseline. The console shows you the lines; noticing the trend is on you. Getting the equivalent in CloudWatch means wiring up metric filters, alarms, and anomaly detection by hand.
5. History past retention, and offline
LogStitch stores fetched logs in a local SQLite database, so a past incident is still readable after CloudWatch's retention window has expired those logs — and you can read it on a plane with no network. The console only shows what's currently in CloudWatch, online.
6. An MCP server so Claude can query your logs
LogStitch ships a local Model Context Protocol server bound to 127.0.0.1, exposing tools to search logs, drill into invocations, list error patterns and anomalies, and pull cost summaries. Claude Code or any MCP-aware client on your machine can debug your Lambda logs by conversation — with your AWS credentials staying in the Keychain. The console has no equivalent.
"Isn't CloudWatch free?" — the honest answer
Yes. Reading logs in the CloudWatch console costs nothing beyond the ingestion and storage you already pay for. LogStitch is $49 (Personal) or $99 (Business), once. So the comparison isn't dollars against dollars — it's a one-time price against your time.
Here's the time cost the console hides. It's 2pm, the error rate on createUser just spiked, and you need a failing invocation to look at:
- Open the log group. The failures are spread across dozens of streams (one per warm container), so you switch to "Search log group."
- Filter for
ERROR. The results interleave error lines from many different invocations by timestamp. - Pick one, copy its
RequestId, then filter again on that ID to isolate the single invocation. - Read
START→ your lines →ERROR→END, mentally skipping theREPORTboilerplate, and expand the one-line JSON error blob to actually read it. - Repeat for the next failing request. And the next incident. And the one after that.
In LogStitch the same task is: open createUser, click the spiking error pattern (already clustered with a count), click a failing invocation, read the formatted timeline with the JSON error expanded. Minutes become seconds — and it's seconds every incident, not just once.
So do the math on your own time, not ours: if invocation-first debugging saves you even 20 minutes a week, the one-time Business license pays for itself in well under a working day of saved effort, and everything after that is free. But if you only open Lambda logs a handful of times a month, that time saving never adds up — stay on the free console, and we'll happily tell you so.
LogStitch fetches logs through your own AWS credentials, so the standard CloudWatch API charges for retrieving logs (FilterLogEvents/GetLogEvents) land on your AWS bill either way — the same calls the console makes on your behalf. LogStitch caches fetched ranges locally, so re-reading the same window doesn't re-hit AWS.
Workflow: same task, both tools
The same job, walked through each. "Find a failing createUser invocation from the 2pm spike and see why it broke."
In the CloudWatch console
- Open the
/aws/lambda/createUserlog group, switch to the right region. - Concurrent invocations are spread across streams, so choose "Search log group" for a merged view.
- Filter
ERROR. Results interleave error lines from many invocations by timestamp. - Pick one, copy its
RequestId. - Filter again on that request ID to isolate the single invocation.
- Read it top to bottom, skipping
START/END/REPORTnoise and expanding the JSON error blob by eye.
In LogStitch
- Open
createUser. The Patterns tab already shows the spiking error, clustered with its count. - Click the pattern, then click any of the failing invocations under it.
- Read the invocation as one formatted timeline — JSON error expanded, level-badged, cold-start and duration in the header.
The console flow isn't broken — it's what a general-purpose log viewer over per-container streams requires. The LogStitch flow is what becomes possible when the tool already knows a "Lambda invocation" is the thing you're looking for.
When to use each
A practical decision framework, by the question you're actually trying to answer.
FAQ
Does LogStitch replace CloudWatch?
CloudWatch is free to read — why pay for LogStitch?
Why is reading Lambda logs in the CloudWatch console so painful?
Can LogStitch read Lambda logs older than my retention window?
Do I need to change my Lambda code or set up X-Ray?
Will LogStitch work without AWS console access?
logs:FilterLogEvents, logs:GetLogEvents). You do not need a console login. Credentials are stored in the macOS Keychain and never leave your machine.Read your CloudWatch logs the way Lambda actually runs.
Free 14-day trial. No card, no account, no telemetry. Point it at your AWS profiles and see your invocations grouped and stitched in under a minute.