Error Tracking

VibePing automatically captures JavaScript errors on your site. No extra configuration — if you've installed the tracking script, errors are already being recorded. This is especially valuable for vibe-coded apps where things break in production in ways you didn't anticipate.

How Auto-Capture Works

VibePing hooks into two browser APIs to catch errors:

window.onerror — catches uncaught exceptions from synchronous code, like referencing an undefined variable or calling a method on null.

window.onunhandledrejection — catches unhandled Promise rejections, like a failed fetch() call where you forgot the .catch().

Both handlers fire automatically. When an error occurs, VibePing packages up the error details and sends them to your project's ingestion endpoint alongside your other analytics events.

What Gets Captured

Each error event includes:

You also get the standard context VibePing attaches to all events: page URL, browser, screen size, and session ID.

Source Maps

VibePing captures raw stack traces as the browser reports them. If you're using a bundler (Webpack, Vite, Turbopack, esbuild — basically everyone), the file paths and line numbers in the stack trace will point to your bundled/minified code, not your source files.

This means you'll see something like:

TypeError: Cannot read properties of undefined (reading 'name')
    at https://myapp.com/_next/static/chunks/app-d8f2a1.js:1:23847

Instead of the actual file and line in your source code.

To get readable stack traces, deploy source maps to your hosting provider. Most platforms (Vercel, Netlify, Cloudflare Pages) can serve source maps in production or make them available for debugging tools. VibePing doesn't process source maps itself — the raw trace is what you get in the dashboard.

Tip: If you're on Vercel, source maps are generated during build. You can use browser DevTools to map errors back to source, or enable source map uploads for your error monitoring workflow.

Viewing Errors in the Dashboard

The Errors page in your VibePing dashboard shows:

• Error list — all captured errors, most recent first
• Grouping by message — identical errors are grouped so you can see how many times each one occurred instead of scrolling through thousands of duplicates
• Frequency — how often each error fires, so you can prioritize the ones hitting the most users

Click into any error group to see the full stack trace, the page it occurred on, and the browser/device context.

Common Error Patterns

If you're shipping apps built with AI assistance, you'll see certain errors come up repeatedly. Here's what to look for:

"undefined is not a function" / "Cannot read properties of undefined"

The most common error in JavaScript, period. Usually means you're accessing a property on something that's null or undefined. In vibe-coded apps, this often happens when:

• API responses don't match the shape your code expects
• A component renders before data has loaded
• Optional chaining (?.) was missed somewhere

Fix: add null checks, use optional chaining, and handle loading states properly.

Network Failures

TypeError: Failed to fetch

The user's network dropped, your API is down, or there's a DNS issue. These will show up as unhandled promise rejections if your fetch() calls don't have error handling.

Fix: wrap fetch calls in try/catch, show the user a retry option, and don't treat network errors as unexpected.

CORS Issues

TypeError: NetworkError when attempting to fetch resource

Your frontend is calling an API that doesn't return the right CORS headers. The browser blocks the response, and your code throws because it expected data. Common when calling third-party APIs directly from the browser.

Fix: proxy the request through your own backend, or configure CORS headers on the API server.

ResizeObserver Loop Errors

ResizeObserver loop completed with undelivered notifications

This one is mostly harmless — it's a browser quirk that fires when layout changes happen during a resize observation cycle. You'll see it a lot with dynamic UIs. It rarely indicates a real problem but it'll clutter your error list.

ChunkLoadError

ChunkLoadError: Loading chunk app-123 failed

Happens after you deploy a new version. Users who have an old tab open try to navigate, and the browser requests a JS chunk that no longer exists on the server. Next.js apps are especially prone to this.

Fix: not much you can do besides handling the error gracefully and prompting the user to refresh.

Manual Error Tracking

Want to track errors that you catch yourself? Use the track method with an error event:

try {
  await riskyOperation();
} catch (err) {
  window.__vibeping.track('error_caught', {
    message: err.message,
    stack: err.stack,
    context: 'checkout_flow'
  });
}

This is useful for errors you handle gracefully but still want visibility into.

Limitations

A few things to be aware of:

Client-side only. VibePing runs in the browser. Server-side errors (API routes, serverless functions, database failures) won't be captured. You need server-side logging for those.

No React error boundary integration by default. React catches errors in its component tree via error boundaries, which means those errors don't bubble up to window.onerror. If you're using error boundaries, add manual tracking inside them:

class ErrorBoundary extends React.Component {
  componentDidCatch(error, errorInfo) {
    window.__vibeping?.track('react_error', {
      message: error.message,
      stack: error.stack,
      component_stack: errorInfo.componentStack
    });
  }
 
  render() {
    if (this.state.hasError) {
      return <FallbackUI />;
    }
    return this.props.children;
  }
}

Cross-origin script errors. If you load third-party scripts without crossorigin="anonymous", the browser will sanitize error details to just "Script error." with no stack trace. This is a browser security feature, not a VibePing limitation. Add the crossorigin attribute to your script tags to get full error details.

Error Alerts

VibePing can send you email alerts when error spikes are detected. The alert system runs hourly and checks each project for unusual error activity.

How spike detection works:

• VibePing compares the number of errors in the last hour against the previous hour
• An alert fires when both conditions are met:
  • At least 5 errors occurred in the last hour (avoids noise from occasional one-off errors)
  • The error count is 3x or more the previous hour's count (actual spike)
• If the previous hour had zero errors, any 5+ errors in the current hour triggers an alert

What the alert email includes:

• Project name
• Error count for the current and previous hour
• Percentage change
• Direct link to the errors page in your dashboard

On VibePing Cloud (app.vibeping.dev): Error alerts are enabled automatically for all projects. No configuration needed.