Stop Buying Error Tracking for Problems Error Tracking Can't Solve

I spent three hours last week debugging a scheduled import job that "worked fine" according to our error tracker. The Sentry dashboard was clean. No exceptions. No alerts. But the job hadn't actually run in six hours, and we only noticed because a client called asking where their data was. That's when it hit me: I'd been using the wrong tool for the wrong problem, and I'm probably not alone.

Most of us reach for Sentry or Bugsnag the moment we set up a background job, treating error tracking as a catch-all monitoring solution. It's not. And the original article nailed something I've been frustrating over for months, error tracking excels at one specific job: capturing and grouping exceptions. Everything else? That's a different conversation entirely.

The Three Questions Your Monitoring Actually Needs to Answer

Here's what I've learned the hard way: when you're operating a scheduled import system, you're not just asking "did an error happen?" You're asking three separate questions, and they each need different tools.

First: was the job triggered? Second: did it fail with an exception? Third: did it finish with reasonable results? Error tracking only answers the middle one. If a job silently doesn't run, Sentry stays quiet. If a job finishes with zero results when it should have five thousand, your error inbox tells you nothing. That's not a bug in Sentry, it's a misunderstanding of what error tracking is for.

I see teams building increasingly elaborate logic around their error trackers, trying to force them to answer questions they were never designed for. We add custom tags, we set thresholds, we create weird alert rules. Meanwhile, the actual problem, missing heartbeat signals and anomalous result counts, goes unmonitored because we're looking at the wrong dashboard.

The Architecture That Actually Works

The article lays out something simple but powerful: separate your concerns. Use error tracking for exceptions. Use a heartbeat monitor (like Healthchecks) for confirming jobs actually ran. Use application-level logging or metrics for business logic questions like "are the result counts plausible?"

The key is that run ID I mentioned, a generated identifier that travels with the job from start to finish. Every stage of the import gets logged or tracked with that same ID. Start event. Result summary. Any caught exceptions. Same ID across the board.

I tested this approach on a Node.js import service last month, and the incident reconstruction became boring in the best possible way. When something went wrong, I could follow a single thread through logs, metrics, and error reports. No jumping between dashboards. No missing context.

What I'd Actually Do Differently

Here's where I diverge from the article slightly: I don't think you need to choose between these tools as an either-or situation. You need to architect how you use them. Sentry is still valuable for uncaught exceptions and development-time debugging. But treat it as one signal among several, not the primary one.

I also think application-level events matter more than the article implies. A zero-result run might be legitimate in some contexts and catastrophic in others. That knowledge lives in your domain logic, not in a monitoring platform. Log that decision explicitly. Make it queryable. Let your future self (or your on-call person at 3 AM) understand not just what happened but why it should or shouldn't have happened.

Here's a basic pattern I've settled on:

// Track the import lifecycle with a run ID
const runId = crypto.randomUUID();

logger.info({
 event: 'import_started',
 runId,
 timestamp: new Date(),
 source: 'api_name'
});

try {
 const results = await importData();
 
 logger.info({
 event: 'import_completed',
 runId,
 recordsProcessed: results.success,
 recordsFailed: results.failed,
 timestamp: new Date()
 });
 
 // Only alert if result count breaks contract
 if (results.success === 0 && results.expected > 0) {
 await alerting.warn({
 runId,
 message: 'Import completed with zero records'
 });
 }
} catch (error) {
 Sentry.captureException(error, {
 tags: { runId }
 });
 
 logger.error({
 event: 'import_failed',
 runId,
 error: error.message
 });
}

// Separate heartbeat check
await healthcheck.ping({ name: 'import_job' });

The run ID threads through everything. The result count gets logged as data, not as an error. The heartbeat ping is independent, it fires whether or not the import succeeded.

My Honest Take

I think a lot of us gravitated toward comprehensive error tracking platforms because they felt like the "grown-up" choice. Sentry feels more professional than a simple HTTP ping to Healthchecks. But professionalism isn't about using the fanciest tool, it's about using the right tool for the actual problem.

This doesn't mean abandoning Sentry. It means being honest about what you're using it for and building the rest of your monitoring architecture to fill the gaps it leaves.

What's Your Setup?

How are you currently monitoring background jobs? Are you leaning on error tracking alone, or have you built a multi-signal approach? I'm genuinely curious what works at different scales, this is one of those problems where the answer probably changes based on your team size and SLA requirements.

Source: This post was inspired by "Simple Error Tracking API for Node.js React SaaS App Imports" by Dev.to. Read the original article