Rate Limiting

Rate limiting protects both the service and the destination during failure storms. A single retry loop or cascading dependency failure can produce thousands of errors per minute. Without a cap, the SDK itself becomes a source of pressure on your transport and downstream collector.

Default behavior

errorcore limits incident capture to 60 errors per minute by default, evaluated in a sliding window. The first errors in a burst are always captured. Once the threshold is reached, additional errors are dropped until the window resets.

Configuration

import errorcore from "errorcore";

errorcore.init({
  service: "api-gateway",
  transport: { type: "http", url: "https://collector.example.com/v1/errors" },
  encryptionKey: process.env.ERRORCORE_KEY,
  rateLimitPerMinute: 30,
  rateLimitWindowMs: 60000,
});

Suppression tracking

When errors are dropped by the rate limiter, the next incident that does get through includes a rateLimiterDrops field in its completeness section:

{
  "completeness": {
    "rateLimiterDrops": {
      "droppedCount": 42,
      "firstDropMs": 1712620800000,
      "lastDropMs": 1712620830000
    }
  }
}

This tells you that errors were suppressed without hiding the fact that the service was unhealthy. The dropped count, first drop time, and last drop time give enough signal to estimate the severity of the burst.

Choosing a limit

For most services, the default of 60 per minute is a reasonable starting point. Lower it for services where the transport destination has tight ingestion limits. Raise it if you run a high-throughput service and need more coverage during incident windows.

The objective is stability, not silence. A good rate limit keeps the first errors (which carry the most diagnostic value) and suppresses repetitive bursts that would not add new information.