Diagnosing and Resolving Event Drops and Rate Limits in Sentry

The Problem: Missing Events and Quota Exhaustion

When Sentry stops reporting errors or shows a "Rate Limit Reached" warning, the immediate risk is a blind spot in your production monitoring. You cannot distinguish between a stable system and one where critical crashes are occurring but are being dropped by the Sentry platform or the SDK.

The primary cause is typically a mismatch between the volume of events generated by your application and the quota allocated to your Sentry organization. This manifests either as hard drops (quota exhausted) or sampling drops (intentional SDK-side filtering).

Diagnostic Matrix: Identifying the Cause

Symptom	Likely Cause	Verification Point
"Rate Limit Reached" in Dashboard	Monthly quota exhausted or burst limit hit	Project Stats Page
Consistent % of events missing	sample_rate configuration	SDK Initialization Code
Specific error types never appear	ignoreErrors or before_send logic	SDK Configuration
Total silence (no events at all)	Invalid DSN or Network Blockage	Client-side Network Logs

Step-by-Step Resolution Path

1. Verify Platform Quota Status

Before changing code, determine if the issue is server-side. Navigate to the Stats page in your Sentry project dashboard. Look for the "Dropped" metric. If the graph shows a sharp spike in dropped events coinciding with a plateau in received events, you have hit your plan's limit.

2. Implement SDK-Side Sampling

If you are hitting limits due to high traffic, do not rely on Sentry's server-side sampling alone. Use the sample_rate parameter during initialization to reduce the number of events sent over the network. This reduces both your quota consumption and the performance overhead on the client.

// Example: JavaScript SDK Initialization
Sentry.init({
  dsn: 'your_dsn_here',
  // Only send 20% of events to Sentry
  sample_rate: 0.2,
});

Risk: Setting this too low (e.g., 0.01) may cause you to miss rare, non-reproducible edge cases that only occur in specific environments.

3. Filter Noise with ignoreErrors

Many applications generate "noise"—errors from third-party libraries or known non-critical issues (like 404s from bots) that consume quota without providing value. Use the ignoreErrors array to block these at the source.

Sentry.init({
  dsn: 'your_dsn_here',
  ignoreErrors: [
    'NetworkError: Failed to fetch',
    'ResizeObserver loop limit exceeded',
  ],
});

4. Advanced Filtering via before_send

For complex logic—such as dropping events based on HTTP status codes or specific user roles—use the before_send callback. This function allows you to inspect the event object and return null to drop it.

Sentry.init({
  dsn: 'your_dsn_here',
  beforeSend(event) { 
    // Drop events that are just 401 Unauthorized responses
    if (event.exception && event.exception.values[0].value === 'Unauthorized') {
      return null;
    }
    return event;
  },
});

Performance Note: Heavy logic inside beforeSend runs on the main thread for every single event; keep these checks lightweight to avoid impacting application latency.

Verification and Testing

To verify that your changes are working without waiting for a production crash, trigger a manual test event. Run the following command in your application's console or a test script:

// Run this in the application environment
Sentry.captureMessage("Quota Test Event: " + new Date().toISOString());

Check the Real-time Event Stream in the Sentry dashboard. If you have a sample_rate of 0.2, you may need to run this multiple times to see a single event arrive, confirming that sampling is active.

Escalation Criteria

If the following conditions persist after implementing the above, escalate to your infrastructure team or Sentry support:

• Events are missing despite the Stats page showing 0% dropped events.
• The DSN is verified, but network logs show 403 Forbidden responses from the Sentry ingest endpoint.
• Quota is exhausted within minutes of a reset despite a sample_rate of < 0.1.