Bot and Scraper Alerts: An Issue When Automated Traffic Targets Your Site

Last verified on Nov 10, 2026.

When the traffic is not customers

Automation is a large share of traffic on any public site. Most is harmless: search crawlers, uptime pings, partner integrations. Some of it is not. A scraper copies your catalog or directory. A script signs up thousands of fake accounts. A bot tries every coupon code. The requests are individually valid, so nothing errors, and your latency graph barely moves.

Bots and scraping is the Sazabi detection for that. The Sazabi agent sets up sensors for your project and maintains them over time. Sensors are standing questions about your logs, and this one asks: "Is automated traffic targeting this site?" You set nothing up, so you do not define what a bot looks like or maintain an IP blocklist.

What it looks for

• A single client or network making requests at a rate no person would.
• One client walking through a long list of similar pages, such as every product or every profile.
• Headless-browser or scripting user agents against pages meant for people.
• Many addresses behaving as one visitor, with the same request shape moving between IPs.
• Repeated hits on sign-up, search or code-redemption routes far out of proportion to normal use.

Example: one network sweeping a marketplace

This is an example, not output from a real project. A service called listings-web serves product pages. Between 02

2026-11-08T02:14:05Z INFO listings-web GET /listings/10412 status=200 ms=63 ip=192.0.2.14 ua="python-requests/2.31"
2026-11-08T02:14:05Z INFO listings-web GET /listings/10413 status=200 ms=61 ip=192.0.2.15 ua="python-requests/2.31"
2026-11-08T02:14:06Z INFO listings-web GET /listings/10414 status=200 ms=66 ip=192.0.2.16 ua="python-requests/2.31"
2026-11-08T02:14:06Z INFO listings-web GET /listings/10415 status=200 ms=59 ip=192.0.2.14 ua="python-requests/2.31"

No single address is noisy, and every request succeeds. The tell is the sequence of ids, the identical user agent, and a request rate far above what listings-web sees at 2 a.m. on a Sunday. Sazabi investigates and opens an issue. An example of what it could say:

• Name: Sequential scraping of /listings from one network
• Description: Requests to /listings/<id> arrived in id order from addresses in one network, all with the same scripting user agent, at several times the usual overnight rate. Every request returned 200.
• Severity: medium

The evidence shows the id sequence and the shared user agent. The analysis points out that the rate was several times its usual level. That is what moves it from "busy" to "automated".

Why a busy launch does not fire it

A genuine spike looks different from a scraper. Real users arrive with varied user agents, varied paths and a mix of status codes, and the surge follows a campaign or a news item. A daily or weekly rhythm is part of normal traffic and does not count. The agent also reads the logs when it investigates, and an issue is opened only when the problem is real.

How you get told

The issue sends an Issue triggered notification to in-app, email, Slack DM or SMS, or to a shared Slack or Microsoft Teams channel through delivery rules that match severity, component or owning team. Abuse usually belongs to a different team than outages, so a rule on a component, such as the sign-up service, can send it there.

In the thread you can ask questions, such as which paths the network touched or how its rate changed. You can hand the fix to a coding agent with sazabi issues agent-prompt, for example to add rate limiting to the route. You can resolve, ignore or mute the issue from the dashboard, Slack, Teams or the CLI. If the scraper returns while the issue is open or ignored, it folds into the same issue.

What it needs

Per-request logs with a client identifier and a path. CDN and edge logs are the best source: Cloudflare and AWS WAF both work, as do application logs through OpenTelemetry. If your logs carry no client address or user agent, the detection has less to go on.

What it does not cover

• Blocking, challenging or rate limiting. Sazabi reports; those controls live in your edge or app.
• Traffic that never reaches a log you send, or that is logged without a client identifier.
• Deciding whether a crawler is welcome. A search engine bot and a competitor's scraper look the same until someone decides which is which, and that policy is yours.
• Account abuse built on valid logins, which is closer to credential stuffing.

For the vendor-neutral method and thresholds, read the bot detection guide. Issue volume is a metered dimension; see pricing.

Credential attacks on the login route are covered by authentication anomalies.