Abuse and Fraud Alerts: Issues When Bots and Scrapers Hit Your App

Last verified on Nov 10, 2026.

Abuse is traffic that is technically valid and still unwanted. A script that walks your directory page by page, a crawler that ignores your terms, a headless browser that fills a form. Nothing crashes, so no error alert fires. The Sazabi agent sets up sensors for your project and maintains them over time, and one of them watches for exactly this.

The one live signal

Bots and scraping is the sensor for this. You set nothing up. It looks for three things in your request logs:

• High-rate clients, meaning one address or key making requests far faster than a person would.
• Headless browsers, automated clients that load pages the way a browser does.
• Rotating IPs, where one set of requests arrives from many addresses to dodge per-address limits.

That is the full list of what is live for this category today. Fake signups, card testing, promo abuse and account farming are not covered by their own signals. The sections below are specific about what the one signal can and cannot tell you.

Example: a directory scrape

This is an example, not output from a real project. The service name and addresses are made up. Your marketing-site service logs every request to the people directory. The log shows this:

2026-11-08T09:41:12Z INFO  marketing-site GET /directory?page=118 ip=192.0.2.14  ua="HeadlessChrome/118.0"
2026-11-08T09:41:12Z INFO  marketing-site GET /directory?page=119 ip=192.0.2.77  ua="HeadlessChrome/118.0"
2026-11-08T09:41:13Z INFO  marketing-site GET /directory?page=120 ip=192.0.2.203 ua="HeadlessChrome/118.0"

No single address is loud. Each makes a few requests. Together they read page after page in order, with one user agent that no customer uses. The sensor's question is about the shape: "Tell me when one kind of client reads far more pages than a person would, even if the requests come from many addresses."

The issue could be named "Coordinated directory scraping from rotating addresses", with medium severity. The description says when it began, how many addresses took part and what they read. The evidence is the lines above and the total request share.

What happens after it fires

A sensor firing records a signal and starts an investigation. If the traffic is a harmless crawler you already allow, the investigation closes without an issue. If it is real, an issue opens. The CLI lists the underlying signals with sazabi signals list --type sensor.

In the issue thread you can ask the next questions: which pages were read, whether any account was logged in, whether the same user agent appeared last week. Hand a fix such as a rate limit on that route to a coding agent with sazabi issues agent-prompt.

Notifications use the normal Issue triggered flow. Many teams leave bot issues in the in-app feed and send only high severity to a shared channel with a delivery rule. Repeats fold into an open or ignored issue, so a scraper that comes back every hour does not open a new issue every hour.

What you need

Request logs from where traffic first lands. That is usually your edge provider, load balancer or web server, with the client address, path and user agent. The Cloudflare integration is one route. The AWS integration covers load balancer logs. Without a user agent or client address field, the sensor has far less to work with.

What it does not cover

• Card testing, fake signups and promo abuse. They need a question about your own events, and no dedicated signal exists for them today.
• Abuse by logged-in users who stay under every rate threshold. Look at suspicious access for odd data pulls by a single actor.
• Blocking. The sensor reads logs after the fact.
• Bots that blend in perfectly, with human-like timing and consistent browsers. A sensor sees what the logs show.

Detected issues are metered, so see pricing.

Related

For the practical side of finding abuse in logs by hand, read the guide to bots and scraping detection and the abuse and fraud guide. For exploit traffic, see active attacks.