Qaid
ARTICLE

Console Error Capture: Debug Without Asking

Automatically capture JavaScript console errors with user feedback to debug issues faster.

Qaid Team

One of the most frustrating aspects of bug reports is the back-and-forth: “What did you click?” “Did you see any error messages?” “Can you try again and tell me what happens?” Users rarely check the browser console, and even fewer know how to copy error messages. With Qaid’s automatic console error capture, those conversations become a thing of the past.

How It Works

When the Qaid embed initializes on your page, it quietly starts listening to console output. Every console.error(), console.warn(), and console.log() call gets captured and timestamped. When a user submits feedback, these console messages are automatically bundled with their submission.

// These errors are automatically captured during the user's session
console.error("Failed to load user profile");
console.warn("Deprecated API endpoint used");
console.log("User clicked checkout button");

The embed keeps the most recent 20 messages to avoid memory bloat while still providing enough context to understand what happened before the user reported an issue.

Zero Configuration Required

Console capture is enabled by default. There’s nothing to configure:

<script
  src="https://unpkg.com/@qaiddev/thumbs-embed"
  data-endpoint="/api/feedback"
></script>

That’s it. Every feedback submission now includes console errors automatically.

What Gets Captured

The captured errors include three key pieces of information:

  1. Message: The full text of the console output
  2. Level: Whether it was an error, warn, or log
  3. Timestamp: Exactly when it occurred

Here’s what a typical captured error looks like in your dashboard:

[14:32:15] [ERR] TypeError: Cannot read property 'name' of undefined
[14:32:15] [ERR]     at UserProfile.render (profile.js:142)
[14:32:14] [WRN] API response slower than expected: 2340ms
[14:32:10] [LOG] Fetching user data for id: 12345

This timeline tells a story. You can see the user requested their profile data, the API was slow to respond, and then something failed when trying to render undefined data. Without asking a single question, you know exactly what went wrong.

Viewing Errors in the Dashboard

When you open a feedback item in the Qaid dashboard, any captured console errors appear in the details panel. Errors are displayed chronologically with color-coded severity levels:

  • Red for errors (console.error)
  • Yellow for warnings (console.warn)
  • Gray for general logs (console.log)

The timestamp helps you correlate errors with the user’s actions. If they reported “the page froze when I clicked Save,” you can trace back through the logs to find the exact sequence of events that led to the problem.

Using Errors for Escalation Rules

Console errors become even more powerful when combined with escalation rules. You can configure rules that automatically escalate feedback based on error patterns:

Escalate Critical Errors

Set up a rule to immediately notify your team when feedback contains specific error patterns:

  • Pattern: TypeError|ReferenceError|SyntaxError
  • Action: Send Slack notification to #engineering-alerts

Track API Failures

Monitor for backend issues reported by users:

  • Pattern: API|fetch|NetworkError|500
  • Action: Create high-priority ticket

Detect Payment Issues

Payment-related errors need immediate attention:

  • Pattern: payment|stripe|checkout|billing
  • Action: Alert on-call engineer

These rules ensure that critical issues don’t sit in a queue while your team manually reviews feedback.

Privacy Considerations

Console capture is designed with privacy in mind:

  1. No sensitive data filtering needed: The embed captures exactly what your code logs. If you’re already careful about not logging sensitive data to the console, you’re covered.

  2. Session-scoped: Errors are only captured from when the embed loads until feedback is submitted. Previous sessions aren’t affected.

  3. User-initiated: Errors are only sent when a user actively submits feedback. Passive error collection doesn’t happen.

If you log sensitive information to the console during development, consider using environment checks:

if (process.env.NODE_ENV === 'development') {
  console.log('Debug: user token', token);
}

Real-World Debugging Scenarios

Scenario 1: The Mysterious Crash

A user reports “the app crashed when I tried to upload a file.” Without console capture, you might spend hours trying to reproduce the issue.

With console capture, you see:

[10:15:32] [LOG] Starting file upload: report.pdf (2.4MB)
[10:15:33] [WRN] File size exceeds recommended limit
[10:15:35] [ERR] RangeError: Maximum call stack size exceeded

Immediately you know: large file uploads are causing a stack overflow, likely in your chunking logic.

Scenario 2: Intermittent Failures

Users occasionally report “sometimes the page doesn’t load properly.” These intermittent bugs are notoriously hard to track down.

Console errors reveal:

[16:45:01] [ERR] Failed to fetch: net::ERR_CONNECTION_TIMED_OUT
[16:45:01] [ERR] CDN resource unavailable: styles.css
[16:45:02] [WRN] Rendering with fallback styles

Now you know your CDN has availability issues, and you can investigate or switch providers.

Scenario 3: Third-Party Integration Issues

A user complains that “the chat widget isn’t working.” You don’t control the chat widget code, but console capture shows:

[09:22:14] [ERR] ChatWidget: Failed to initialize - invalid API key
[09:22:14] [WRN] ChatWidget: Falling back to offline mode

The issue isn’t your code at all—it’s an expired API key for your chat provider.

Best Practices

Log Meaningful Context

Since console messages are captured, make your logs useful:

// Less helpful
console.error("Error");

// More helpful
console.error(`Failed to save document ${docId}: ${error.message}`);

Use Appropriate Log Levels

Reserve console.error() for actual errors. Use console.warn() for potential issues and console.log() for general information. This makes it easier to scan captured logs for the real problems.

Add Breadcrumbs

Log important user actions so you can trace their journey:

function handleCheckout() {
  console.log("User initiated checkout");
  // ... checkout logic
}

When something goes wrong later, these breadcrumbs help you understand the user’s path.

Technical Details

The console capture system works by wrapping the native console.error, console.warn, and console.log methods. The original methods are preserved and called normally—your existing console output continues to work. The wrapper simply records a copy of each message.

When the user submits feedback, the captured errors are serialized and sent along with the feedback payload. The API stores them as a JSON array associated with that feedback item.

The 20-message limit uses a rolling buffer: when a new message arrives and the buffer is full, the oldest message is dropped. This ensures memory usage stays constant even on pages with verbose logging.

Summary

Console error capture transforms vague bug reports into actionable debugging information. Instead of “something broke,” you get a complete timeline of what happened on the user’s machine. It requires no configuration, respects user privacy, and integrates seamlessly with escalation rules to ensure critical issues get immediate attention.

The next time a user reports a problem, you’ll have everything you need to fix it—without asking a single follow-up question.

Back to all articles