FlareLog vs Sentry: Which One Actually Catches Your Cloudflare Worker Crashes?

You shipped a Lovable app to Cloudflare Workers. You wired up Sentry because that's what everyone does. Then at 2am, users start hitting 500s. You open Sentry and see... a few client-side errors. You open Cloudflare's dashboard and see... Error 1101 with zero logs. Sentry missed it entirely.

This isn't a Sentry bug. It's a fundamental architectural mismatch: Sentry is SDK-based, and on Cloudflare Workers, the most damaging failures happen before your SDK gets a chance to fire. Below is an honest breakdown of where Sentry wins, where it loses, and when you should pick FlareLog instead — or run both side-by-side.

TL;DR

Sentry is the right choice if you have an SRE team, run multiple languages, and need session replay or deep performance profiling. FlareLog is the right choice if you're a vibe coder shipping React + Cloudflare Workers with an AI tab open, and you want to catch crashes Sentry can't see, monitor your Cloudflare bill, and let your AI debug production without leaving the editor.

Where Sentry Still Wins (Be Honest First)

Sentry has been the default for error monitoring for over a decade, and for good reason. There are areas where FlareLog doesn't compete today:

• Session replay — Sentry records user sessions, including DOM mutations and clicks. FlareLog doesn't.
• Deep performance profiling — Sentry's tracing and spans are mature, with language-specific profilers for Python, Node, Java, and more.
• Source map symbolication — Sentry's source map upload pipeline is battle-tested. FlareLog's is on the roadmap.
• Ecosystem breadth — Sentry has hundreds of integrations (Django, Rails, Spring, Express, Next.js, React Native, Unity). FlareLog has a handful.
• Issue grouping — Sentry's fingerprinting and grouping logic is genuinely better at deduplicating similar errors.

If you've outgrown Lovable, have a dedicated observability team, and need any of the above, keep Sentry. This post isn't about replacing it — it's about the gap Sentry leaves on the Cloudflare Workers layer, and how to fill it.

Wedge 1: Sentry Can't See Worker Crashes That Happen Before Your Code Runs

This is the single biggest gap. Sentry's Cloudflare Workers SDK works by wrapping your fetch handler and catching exceptions inside it. That works for errors thrown during request handling. It doesn't work for:

• CPU timeout — your Worker hits the 50ms (free) or 30s (paid) CPU limit. Sentry's captureException never fires because the runtime terminates execution mid-flight.
• Memory exhaustion — your Worker exceeds 128MB. Immediate kill, no graceful shutdown, no SDK call.
• Startup failure — your Worker throws during module initialization (bad env var, syntax error in a dynamic import, missing binding). Your fetch handler never even registers, so Sentry never wraps it.
• Subrequest timeout — a fetch() call hangs past the subrequest limit. Same outcome.

All of these surface as Error 1101 to your users, and Sentry logs nothing. You're back to debugging by guesswork.

FlareLog solves this with a Tail Worker layer that runs out-of-band, after your producer Worker finishes — whether it succeeded or crashed. The Tail Worker receives the execution result, including outcome, CPU time, duration, and any uncaught exceptions. Even when your Worker dies on line 1.

// flarelog-tail-worker.js
export default {
  async tail(events, env, ctx) {
    for (const event of events) {
      // This fires even if the producer Worker crashed before logging
      if (event.outcome === "exception" || event.outcome === "exceededCpu") {
        await fetch("https://api.flarelog.dev/ingest", {
          method: "POST",
          headers: { "Authorization": `Bearer ${env.FLARELOG_API_KEY}` },
          body: JSON.stringify({
            level: "ERROR",
            message: `Worker ${event.outcome}`,
            metadata: {
              outcome: event.outcome,
              cpuTime: event.cpuTime,
              duration: event.duration,
              exceptions: event.exceptions,
            },
          }),
        });
      }
    }
  },
};

Sentry has no equivalent. Their SDK is in-band only.

Wedge 2: Sentry Has No Concept of Cloudflare Billing

A misconfigured KV loop, a forgotten cursor on a D1 query, or an accidentally-recursive R2 list operation can rack up hundreds of dollars in a few hours. Cloudflare's cost metrics lag 15–60 minutes behind real time, and Sentry has zero visibility into any of it — Sentry tracks errors and performance, not Cloudflare operations.

FlareLog estimates per-request cost in real time from CPU time, subrequest count, and class A/B operation counts reported by the Tail Worker. When a Worker starts burning money, FlareLog fires an alert the second spend crosses your threshold — not 45 minutes later when Cloudflare's billing dashboard catches up.

For Lovable users especially, this is the scary failure mode. You built the app in an afternoon with AI. You don't have a deep mental model of every code path. A cost burn alert is the difference between a $4 surprise and a $400 surprise.

Sentry will never build this. It's not their domain. It is ours.

Wedge 3: Sentry's Workflow Is Browser-Tab Debugging. FlareLog's Is AI-Tab Debugging.

Here's the standard Sentry debugging flow when something breaks at 2am:

1. Open browser
2. Navigate to sentry.io
3. Find your project
4. Click into the issue
5. Copy the stack trace
6. Open Cursor / Claude / Lovable
7. Paste the stack trace
8. Ask "what could cause this?"
9. AI guesses based on the snippet you pasted
10. Apply the fix, deploy, hope

FlareLog ships an MCP server that connects your production logs directly to Lovable Agent, Cursor, Claude Desktop, or Windsurf. Your AI can query live logs in-context:

• "Why did /checkout fail in the last hour?"
• "Show me every D1 timeout this week."
• "Which Worker has the highest CPU time right now?"

The AI gets back structured log payloads with full stack traces, trace IDs, and metadata — and can suggest code fixes without you ever opening a browser. For someone who built their app with AI, this is the natural debugging workflow. Sentry's architecture will always require the browser-tab detour.

// cursor settings.json / claude_desktop_config.json
{
  "mcpServers": {
    "flarelog": {
      "url": "https://mcp.flarelog.dev",
      "headers": {
        "Authorization": "Bearer fl_your_api_key"
      }
    }
  }
}

In Lovable itself, it's even simpler — Connectors → Add MCP server → paste the URL. No JSON, no terminal.

Wedge 4: Native TanStack Start Middleware and a React Error Boundary Built for Lovable

Lovable generates a specific stack: React + Cloudflare Workers + TanStack Start. Sentry supports Cloudflare Workers, but wiring it into TanStack Start server functions requires manual transport setup, source map configuration, and per-route instrumentation — easily 15+ lines across multiple files.

FlareLog ships a dedicated TanStack Start middleware and a React ErrorBoundary component built for exactly this stack:

// React + Lovable
import { flarelog } from "@flarelog/sdk";
import { FlareLogErrorBoundary } from "@flarelog/sdk/react";

const logger = flarelog({ apiKey: process.env.VITE_FLARELOG_API_KEY });

<FlareLogErrorBoundary logger={logger}>
  <App />
</FlareLogErrorBoundary>

// TanStack Start
import { flarelog } from "@flarelog/sdk";
import { tanstackStartMiddleware } from "@flarelog/sdk/tanstack-start";

const logger = flarelog({ apiKey: process.env.FLARELOG_API_KEY });
app.use(tanstackStartMiddleware(logger));

Three lines. The same logger works on the client (via the React SDK) and on the server (via the TanStack middleware), so errors from either layer land in the same dashboard with shared trace IDs. Sentry can do this, but it takes meaningfully more wiring — and if you didn't write the codebase yourself (which is the whole point of Lovable), every extra line of config is a place to get it wrong.

Wedge 5: Free Tier Is 10× Bigger, With Logs (Not Just Errors)

Sentry's free tier is 5,000 error events per month, with a 30-day retention window. No general logs — only error events. Once you exceed 5k errors, you're pushed onto the Team plan at $26+/month.

FlareLog's free tier is 50,000 log events per month — errors, warnings, info, and structured logs all count toward the same pool. Retention is 90 days on free (vs. Sentry's 30). For a Lovable-built side project or MVP that's still finding its feet, this is the difference between "free forever" and "surprise upgrade email in week three."

This isn't a rounding difference. It's a 10× gap, and the events FlareLog counts are broader. Sentry is pricing for teams that have outgrown the free tier; FlareLog is pricing for the people who haven't yet.

Side-by-Side Comparison

Capability	FlareLog	Sentry
Catches silent Worker crashes (CPU, OOM, startup)	Yes — Tail Worker layer	No — SDK-only
Real-time Cloudflare cost alerts	Yes	No
MCP server for AI debugging	Yes	No
Native TanStack Start middleware	Yes — one-liner	Partial — manual wiring
Free tier events/month	50,000 log events	5,000 error events
Free tier retention	90 days	30 days
Setup time on Lovable stack	~3 lines, <2 min	~15 lines + transport + source maps
Session replay	No	Yes (premium)
Performance profiling	Cloudflare-native	Deep, multi-language
Source map symbolication	Coming	Yes, mature
Ecosystem integrations	Handful	Hundreds

The first seven rows are where FlareLog wins. The last three are where Sentry wins. Both can be true.

When to Use Which

Use FlareLog alone if:

• You built your app with Lovable, Cursor, or another AI tool
• You deploy to Cloudflare Workers (with or without TanStack Start)
• You don't have a dedicated SRE or observability team
• You want your AI to debug production without leaving the editor
• You're cost-conscious about both your Cloudflare bill and your observability bill

Use Sentry alone if:

• You run multiple backend languages (Python, Java, Ruby, .NET) in production
• You need session replay for UX debugging
• You have a dedicated team that already knows Sentry
• You're not on Cloudflare Workers

Run both side-by-side if:

• You're on Cloudflare Workers and you need Sentry's session replay or source map maturity
• You want FlareLog for the Workers layer (crashes, cost, AI debugging) and Sentry for client-side errors and replay
• You're transitioning off Sentry and want overlap during the migration

Both can ingest from the same Worker without conflict. Sentry's SDK wraps your fetch handler; FlareLog's Tail Worker runs out-of-band after. They don't interfere.

How to Run Both Side-by-Side

If you decide to keep Sentry for client-side and add FlareLog for the Workers layer, setup takes about five minutes:

# 1. Install both SDKs
npm install @flarelog/sdk @sentry/cloudflare

// worker.ts — Sentry wraps the fetch handler (in-band)
import * as Sentry from "@sentry/cloudflare";
import { flarelog } from "@flarelog/sdk";

const logger = flarelog({ apiKey: env.FLARELOG_API_KEY });

export default Sentry.withSentry(
  { dsn: env.SENTRY_DSN },
  {
    async fetch(req, env, ctx) {
      // Your existing handler
      logger.info("request", { url: req.url });
      return new Response("ok");
    },
  }
);

# wrangler.toml — FlareLog runs as a Tail Worker (out-of-band)
[[tail_consumers]]
service = "flarelog-tail-worker"

That's it. Sentry catches errors thrown inside your fetch handler; FlareLog catches everything else — including crashes Sentry never sees — plus cost burn, plus gives your AI a direct line to the logs via MCP.

Summary

Sentry is a great product. It is not purpose-built for Cloudflare Workers, and the gap shows up at the worst possible moment: when your Worker crashes silently and Sentry logs nothing. FlareLog exists to fill that gap.

The honest pitch is this: Sentry is great if you have an SRE team. FlareLog is great if you have an AI tab open. For Lovable users — and anyone else shipping React + Cloudflare Workers with AI assistance — FlareLog catches the crashes Sentry can't, watches the bill Sentry ignores, and lets your AI debug production without making you paste stack traces back and forth all night.

Start free at flarelog.dev/login. 50,000 log events/month, 90-day retention, no credit card. Or read the FlareLog vs Sentry comparison page for the full breakdown.

---

Written by Chiheb Nabil, founder of FlareLog. Building observability tools for developers shipping on Cloudflare Workers — especially the ones who built their app with AI and need their AI to help debug it.