Rate Limit Violation Detector

Not every overload is an attack and not every burst is a botnet — but a single IP making hundreds of requests in a minute is outside every normal traffic shape. Rate-Limit Violation Detector assigns every request in your log to a fixed time window, counts requests per IP inside each window, and flags any IP whose window count breaks your configured rate limit.

Unlike brute-force detectors, it watches raw request volume over all status codes — so API scraping, endpoint hammering, and abusive crawlers surface even without a single failed login. Windows are fixed and aligned to the timestamp of the earliest request found in your log: the first window covers [first, first+N) seconds, the next covers [first+N, first+2N), and so on, with every request assigned to exactly one window by its own timestamp. Each flagged IP is reported with its total traffic across the whole file, how many windows tripped your limit, its single busiest window (the peak), and the timestamps of the worst offending windows so you can go straight to blocking or throttling.

By default, any window that exceeds your threshold is reported as a violation: if the policy says 100 requests per minute per IP and a window shows 140, that is a violation, full stop. An optional Min off-peak setting lets you additionally require a sustained pattern across two or more windows, or a very large single-window spike, before flagging — useful for filtering an isolated short burst that only barely clears the limit once and never repeats.

• Volume-based rate detection — counts every request regardless of status code, so it catches abuse that never trips an auth-failure detector.
• Fixed-window counting — windows are aligned to the earliest timestamp in your log and sized in configurable seconds.
• Requests-per-window threshold — set the exact policy number you want to test against.
• Peak and worst-window reporting — see the single busiest window per IP and its timestamp, not just a total.
• Total-traffic minimum — ignore IPs whose overall volume is too small to matter.
• Optional lonely-spike filter — flags any exceeding window by default, or opt in to requiring sustained or very large bursts.
• Configurable timestamp and IP patterns — adapt the tool to non-standard log formats without leaving the page.
• Local only — nothing uploaded, no network calls.

1. Paste your access or API log.
2. Adjust the timestamp and IP patterns if your log format is not the standard YYYY-MM-DDThh:mm:ss plus dotted-decimal IPv4 shown by default.
3. Set the window in seconds and the max requests allowed per IP within that window — this is your rate-limit policy, expressed the same way most reverse proxies configure it.
4. Decide on Min off-peak. Leave it at No to flag every window that exceeds your limit; switch to Yes only if you specifically want to suppress isolated single-window spikes that are not part of a sustained or extreme burst.
5. Run detection. Violators are listed sorted by peak request count, each with total traffic, number of exceeding windows, and the worst window timestamps.
6. Block or throttle straight from the report — the flagged IPs and their busiest windows are ready to hand to a firewall rule or a proxy config.

Example 1 — Price scraper. An IP pulls the same product API 2,000 times in an hour, peaking at 140 requests in a single 60-second window. With a 100/min cap, that window is flagged as a violation and reported as the worst window, alongside the total of 2,000 requests across the hour.

Example 2 — Endpoint hammer. After a leak, an attacker floods /api/reset at 90 requests per minute. Even without a single auth failure in the log, the volume spike names the IP and the timestamp of the worst window immediately.

Example 3 — Legit crawler calibration. A well-behaved SEO bot does 40 requests per minute across the day — comfortably under a 100/min cap, so it never appears in the violators list, which is exactly the confirmation you want before rolling a new threshold out to production blocking.

Example 4 — A single sharp burst. An IP sends exactly 120 requests within one 60-second window and nothing else all day. With a 100/min limit and Min off-peak left at its default of No, this window is correctly reported as a violation — 120 exceeds 100 — even though the IP was never seen again. Switching Min off-peak to Yes would hide this case unless the spike were roughly three times the limit or spread across more than one window.

• Catches non-auth abuse — scraping, hammering, and crawling that never produce a failed login.
• Simple threshold model — maps directly onto proxy and gateway rate-limit configs.
• Per-IP windows — real per-client rates, not an aggregate that hides individual offenders.
• Correct window math — fixed windows anchored to your data with no off-by-one boundary errors.
• Actionable timing data — the worst window and its timestamp are included, ready for a block rule.
• No hidden default suppression — a real single-window violation is flagged out of the box.
• Private — all processing is client-side.