Fixed Rate Limits Are Always Wrong

You set a rate limit. At the time, it felt right. You looked at your average request rate, added a reasonable buffer, and picked a number.

Then came the first sales event. Black Friday. A major product launch. Traffic spiked to four times the average. Your rate limit, carefully calibrated to the normal baseline, started dropping legitimate events. Customers complained. You raised the limit.

Then came the abuse incident. Someone discovered your webhook endpoint and began hammering it with uniform 10-millisecond interval requests. Your rate limit, now calibrated to handle the sales spike, was high enough that the abuse storm got through before your team noticed. Your target service struggled under the load for 45 minutes.

You lowered the limit. You set it back to something in between — too low for the spike, too high for the abuse. You accepted the tradeoff.

This is the fundamental problem with fixed rate limits: they are calibrated to one point in time with one traffic profile in mind. The traffic changes. The limit does not.

Adaptive rate limiting removes the tradeoff. The limit adjusts continuously to match what is actually happening.

How the Adaptive Multiplier Works

Every hook's rate limit is a baseline from your tier (for example, 100 requests per minute on Free, higher on Pro and Team) multiplied by a continuously updated multiplier.

The multiplier starts at 1.0 and moves between 0.5 (50% of baseline) and 1.5 (150% of baseline). The multiplier is calculated using an Exponential Moving Average (EMA) of recent traffic behavior — the same smoothing technique used in financial time-series analysis and network traffic engineering.

EMA is used specifically because it is resistant to momentary spikes. A single anomalous data point does not dramatically swing the multiplier. The multiplier responds to sustained patterns, not transient noise. This prevents the oscillation that plagues simpler adaptive systems, where the limit swings up for a spike and then overcorrects downward, creating unnecessary drops.

When the Multiplier Rises

Normal traffic at sustained higher-than-average rates. A real event — a product launch, a batch operation, a scheduled job that is running faster than expected — produces a smooth increase in request rate. The EMA detects the sustained increase and adjusts the multiplier upward, providing headroom for legitimate burst traffic to flow without hitting limits.

The multiplier rises gradually, not immediately. A spike that lasts 10 seconds and then disappears will not meaningfully change the multiplier. A sustained elevated rate that lasts 5 or more minutes moves the multiplier upward in proportion to the magnitude of the increase.

When the Multiplier Falls

Abuse patterns. Three signals trigger a downward adjustment:

Too fast: Request intervals that are unrealistically uniform. Human-driven and application-driven webhook providers have natural jitter in their send cadence. A perfectly uniform 50ms interval across 1,000 requests is a signature of automated flooding, not legitimate webhook traffic.

Too uniform: Payloads that are structurally identical across many requests, differing only in a monotonically incrementing field. Legitimate webhook events have natural variation in payload structure based on event type and data. Uniform payloads suggest synthetic traffic.

Signature anomalies: Requests that lack standard provider headers, have unusual user-agent strings, or have payload structures inconsistent with the hook's historical event profile.

When these signals appear together, the multiplier drops. Traffic slows. The abuse pattern encounters resistance. The signals can trigger a dashboard alert (shown in the AdaptiveLimitsWidget as a "Rapid Change Warning") so your team knows the adaptive system is actively suppressing something.

The Free Tier Exception

Free tier hooks always use a multiplier of exactly 1.0. The adaptive mechanism is disabled for Free tier.

This is intentional. The adaptive multiplier provides value for production systems with established traffic patterns and real traffic volume. Free tier is designed for testing, development, and low-volume use cases where traffic patterns are not yet established and the EMA would have insufficient signal to operate correctly. It is also a meaningful differentiator for Pro and Team tiers.

The Dashboard Widget

The AdaptiveLimitsWidget shows you what the adaptive system is doing in real time.

A horizontal progress bar shows the current multiplier within its 0.5–1.5 range. The bar fills from the center: at 1.0, the bar is centered. At 1.5, it extends fully to the right. At 0.5, it extends fully to the left. The visual direction gives you an immediate sense of whether the system is being permissive or restrictive.

Below the bar:

Current multiplier: the exact value (for example, 1.23)
Effective limit: current multiplier times tier baseline, in requests per minute
EMA window: the time window the smoothing is operating over
Rapid Change Warning: appears when the multiplier has moved more than 0.3 in either direction within the last 10 minutes

The Rapid Change Warning is the signal that something unusual is happening. A rapid upward change means the system is absorbing a sudden legitimate spike. A rapid downward change means the system has detected abuse and is suppressing it. Either way, the warning prompts you to look at the traffic pattern in more detail.

Every inbound webhook response also includes the X-RateLimit-Adapted header, which contains the current multiplier value. This header is available in the raw event view and can be used to confirm that the adaptive system is operating for a specific request.

What You Can Stop Doing

Stop tuning limits after every anomaly. The EMA smoothing means your limits adjust to your traffic reality without you reconfiguring anything. After a sales event, the multiplier returns to baseline naturally as traffic normalizes. You do not need to raise limits before the event and lower them after.

Stop choosing between protection and capacity. The adaptive multiplier provides both simultaneously. High-volume legitimate traffic gets additional headroom as the multiplier rises. Abuse patterns get suppressed as the multiplier drops. These are not the same signal, and the system distinguishes between them.

Stop learning about abuse after the fact. The Rapid Change Warning surfaces multiplier movements in the dashboard as they happen. If an abuse pattern triggers a rapid downward adjustment, you see it in the widget before you see it in your target's error logs.

Comparison

| Capability | HookTunnel | ngrok | Webhook.site | Hookdeck | Svix | |---|---|---|---|---|---| | Fixed rate limiting | Yes | Yes | No | Yes | Yes | | Adaptive multiplier (EMA-smoothed) | Yes | No | No | No | No | | Automatic abuse pattern detection | Yes | No | No | No | No | | Dashboard visibility of current limit | Yes | No | No | Partial | No | | X-RateLimit-Adapted header | Yes | No | No | No | No | | Rapid change alerting | Yes | No | No | No | No |

Every competitor uses fixed rate limits. Hookdeck shows retry configuration and has some visibility into delivery attempts, but rate limits are static and manually configured. Svix provides rate limit configuration per endpoint but does not adapt to traffic patterns.

Technical Implementation Notes

The adaptive limiter uses EMA with a configurable alpha (smoothing factor). A lower alpha gives more weight to historical data and produces a smoother, slower-responding multiplier. A higher alpha gives more weight to recent data and produces a more responsive but potentially noisier multiplier.

The default alpha is tuned to respond meaningfully to sustained changes while ignoring transient spikes lasting fewer than 2 minutes. This was validated against real production traffic patterns across the HookTunnel customer base during the feature's development period.

The abuse detection signals (uniform intervals, uniform payloads, signature anomalies) are evaluated in combination, not individually. A single unusual request does not trigger the downward adjustment. A sustained pattern of multiple anomaly signals does. The threshold for sustained abuse detection requires at least 20 consecutive requests exhibiting the anomalous pattern before the multiplier begins moving downward.

Pattern persistence is stored in Supabase at 5-minute intervals. On restart, the adaptive system reloads the persisted pattern state rather than starting fresh. This prevents the restart vulnerability where a restart during an abuse event temporarily resets the multiplier to 1.0 and re-exposes the target.

Scenarios

Sales event on a payment hook. Your e-commerce platform runs a flash sale. Order volume spikes 3x over 20 minutes. Stripe fires payment_intent.succeeded events at 3x normal rate. The EMA detects the sustained elevated rate and moves the multiplier to 1.4 within the first 5 minutes. Effective limit increases proportionally. No events are dropped. When the sale ends, traffic returns to baseline, and the multiplier drifts back toward 1.0 over the next 15 minutes.

Scraper discovering a webhook endpoint. An automated process begins sending structurally uniform POST requests to one of your hooks at 50ms intervals. The uniformity signal triggers within 30 seconds. The payload similarity signal triggers shortly after. The multiplier drops to 0.6 within 2 minutes. The dashboard shows a Rapid Change Warning. Your team sees it. The abuse traffic is largely absorbed by the reduced limit before anyone has had to manually intervene.

Batch job running faster than expected. An internal batch job that processes order confirmations runs a Tuesday import. It sends 800 events in 3 minutes rather than the usual 20 minutes because the dataset was smaller and the import logic ran faster. The EMA detects the spike and raises the multiplier. Most events flow through. Some hit the limit and are queued for immediate retry within the rate window. All 800 are delivered within 4 minutes. No manual intervention. No configuration change required.

FAQ

Can I see the abuse signals that triggered a downward adjustment?

Yes. The Investigations feature captures the abuse signals and provides plain-language narration of what triggered the downward movement. From the AdaptiveLimitsWidget, you can link directly to an investigation for any hook that has had a Rapid Change Warning.

Does the adaptive system interact with the circuit breaker?

Yes, indirectly. When the circuit breaker opens for a target, the adaptive multiplier stops moving — there is no delivery to measure. When the circuit closes and delivery resumes, the multiplier begins operating again from where it left off (the persisted state). This prevents the reopening of the circuit from being immediately overwhelmed by queued events; the multiplier starts conservative and rises as successful delivery is confirmed.

What happens when the multiplier is at 0.5 and an abuse storm continues?

At 0.5, you are at the floor of the adaptive range. Traffic beyond the floor is dropped (with a 429 response) at the standard rate limiter level. The adaptive system does not take the effective limit to zero — the floor of 0.5 ensures that legitimate low-volume traffic still gets through even during an active abuse event. If you need more aggressive suppression for a specific hook, manual rate limit overrides are available at Team tier.

Is the EMA window configurable?

The default EMA window is appropriate for most production use cases. Window configuration is available at Team tier for hooks with unusual traffic profiles — very high-frequency webhooks or very low-frequency webhooks both benefit from window tuning. Contact support to configure non-default windows.

How does this interact with daily request quotas on Free tier?

Free tier uses a static multiplier of 1.0. The adaptive system is not involved. Daily quota enforcement is separate from rate limiting and operates regardless of tier. The daily quota (100 requests per day on Free) is a different control from the per-minute rate limit — one is a throughput control, the other is a consumption control.