Seatext library / BotRefund evidence
Which Metrics Matter Most When Monitoring Bots in Real Time?
To monitor bots effectively in real time, focus on request latency, error rates, and request volume. These three indicators provide the fastest signal that your site is under automated stress or experiencing a bot-driven...
✓ Built for advertisers who need clear, refund-ready traffic evidence.
The Core Metrics for Real-Time Bot Monitoring
When you monitor traffic for bot activity, you need data that reacts instantly. While long-term analytics are useful for strategy, real-time monitoring requires metrics that signal immediate disruption. The most critical metrics are request latency, error rates, and request volume.
Request latency measures how long your server takes to respond. Bots often perform repetitive tasks that can slow down your infrastructure, causing latency spikes. Error rates, specifically 4xx and 5xx status codes, often indicate that bots are hitting non-existent pages or overwhelming your backend. Finally, request volume helps you spot traffic surges that deviate from your typical human baseline.
These three metrics work together. A sudden jump in volume with rising latency and error rates is a strong signal of an automated attack. But each metric alone can be misleading. For example, a legitimate marketing campaign can cause a volume spike. Latency can rise due to a slow database query. Errors can come from a broken page. That is why you need to set thresholds carefully and interpret anomalies in context.
Understanding the Trade-offs in Monitoring
Monitoring is a balancing act between sensitivity and noise. If you set your thresholds too low, you will trigger false alarms for legitimate users. If you set them too high, you will miss sophisticated bot attacks.
| Metric | What it reveals | Risk of ignoring | Best for |
|---|---|---|---|
| Request Latency | Infrastructure strain | Slow user experience | Detecting resource-heavy scrapers |
| Error Rate | Broken paths or attacks | Lost revenue/conversions | Identifying brute-force attempts |
| Request Volume | Traffic anomalies | Budget waste | Spotting large-scale botnets |
Each metric has a different sensitivity profile. Latency is noisy because many factors affect it. Error rates are more stable but can spike from a single misconfigured page. Volume is the most obvious but also the easiest to fake with distributed botnets. You need to weigh these trade-offs when designing your monitoring dashboard.
Why Real-Time Monitoring Matters
Ignoring bot traffic in real time is expensive. For businesses running paid ads, bot clicks can steal up to 20% of your Google and Meta ad budget. Without real-time visibility, you are paying for traffic that never converts. Real-time monitoring allows you to catch these interactions as they happen, rather than discovering the waste at the end of a billing cycle.
Real-time monitoring also protects your infrastructure. A sudden bot surge can exhaust server resources, causing downtime for real users. By detecting the surge early, you can rate-limit or block the offending IPs before they cause damage. This is especially important for e-commerce sites during peak shopping seasons.
Moreover, real-time data helps you respond to attacks quickly. If a bot is scraping your pricing pages, you can adjust your content delivery or add CAPTCHAs. If a bot is brute-forcing login endpoints, you can lock down those routes. The faster you know, the faster you can act.
How Bot Detection Works
Effective detection goes beyond simple volume checks. It requires analyzing behavioral patterns. For example, tools look for superhuman input speeds (under 1ms), robotic linear mouse movements, and grid-aligned paths. These signals help distinguish between a real person and an automated script that lacks the natural jitter and hesitation of human interaction.
Modern bot detection systems use a large set of independent checks. One system, BotRefund, uses 106 independent checks to build a reliable picture of whether a visit is human or automated. These checks cover browser, network, device, and behavior evidence. They include:
- Ghost click detection – catches click activity that happens without the natural sequence of human intent.
- Honeypot trap interactions – watches for bots that respond to hidden or intentionally deceptive page elements.
- Robotic linear mouse movements – flags unnaturally straight pointer paths that rarely appear in real user sessions.
- Absence of humanlike mouse tremor – looks for the tiny imperfections and jitter typical of human movement.
- Superhuman input speed (<1ms) – identifies interactions that happen faster than a person could realistically perform.
- Grid-aligned movement patterns – detects movement that snaps to precise lines or blocks instead of natural curves.
- Absence of clicks or scrolling – highlights sessions that stay too static to match a real browsing journey.
- Unnatural session durations – catches visit lengths that are too short, too long, or too uniform to be human.
These checks are not used in isolation. A single anomaly is not a bot verdict. Privacy tools, travel, corporate networks, and unusual devices can produce unexpected behavior for genuine people. Reliable systems keep each signal as evidence—not a verdict—and cross-check it against independent browser, network, device, and behavior data.
Setting Thresholds for Each Metric
Thresholds are the values that trigger an alert. They must be tuned to your site's normal baseline. Start by collecting historical data for at least two weeks. Calculate the average and standard deviation for each metric.
For request latency, set a threshold at 2-3 standard deviations above the mean. For example, if your average response time is 200ms with a standard deviation of 50ms, a threshold of 350ms might be appropriate. But remember that latency can spike during legitimate events like product launches. Use a rolling window, such as a 5-minute average, to smooth out short-term noise.
For error rates, set a threshold based on your typical error percentage. If your normal error rate is 1%, a threshold of 3% might be reasonable. However, a sudden spike to 10% is almost always a problem. Monitor both the absolute rate and the rate of change. A slow creep upward can indicate a scraping bot that is gradually increasing its requests.
For request volume, set a threshold based on your peak traffic. If your site normally handles 1,000 requests per minute, a threshold of 2,000 might be too high. Instead, use a dynamic threshold that adjusts for time of day and day of week. For example, a 300% increase over the same hour last week is a strong signal.
Thresholds should be reviewed monthly. Your traffic patterns change as your business grows. What was normal six months ago may no longer apply. Also, test your thresholds by simulating bot traffic. This helps you verify that alerts fire correctly and that false positives are minimal.
Interpreting Anomalies in Context
An anomaly is not automatically a bot. You need to look at the whole picture. For example, a spike in request volume from a single IP range might be a botnet. But a spike from many different IPs could be a viral social media post. Check the user-agent strings, referrer sources, and geographic distribution.
Latency spikes can have many causes. A bot might be hammering a specific endpoint, but a slow database query could also cause it. Look at which pages are slow. If it is a login page, it might be a credential-stuffing attack. If it is a search page, it might be a scraper.
Error rates are often the clearest signal. A sudden increase in 404 errors suggests a bot scanning for vulnerabilities. A rise in 500 errors might mean your server is overwhelmed. But also check if a recent code deployment introduced a bug. Cross-reference with your deployment logs.
Context also includes behavioral signals. A visitor that moves a mouse in a perfectly straight line, clicks without any hesitation, and completes actions in under a millisecond is almost certainly a bot. But a user on a touch device might not show mouse movements at all. That is why you need to combine multiple signals.
BotRefund's approach is a good example. It uses 106 independent checks and sends each signal into a prediction AI. The AI evaluates the complete pattern across browser, network, device, and behavior evidence. By seeing how all signals fit together, it identifies a visit as bot or human with 99% accuracy. This corroboration is key to avoiding false positives.
Limitations of Relying on These Metrics Alone
Request latency, error rate, and request volume are useful, but they have limitations. They are reactive. They tell you something is happening, but not necessarily why. They also miss sophisticated bots that mimic human behavior. A bot that uses real browsers, rotates IPs, and adds random delays can bypass these simple metrics.
These metrics also generate false positives. A legitimate user on a slow connection might cause a latency spike. A web crawler from Google or Bing might increase volume and error rates. You need to whitelist known good bots and adjust thresholds accordingly.
Another limitation is that these metrics do not capture the quality of traffic. A bot can generate thousands of requests without affecting latency or error rates if your server is powerful. But those requests still waste resources and skew your analytics. You need deeper behavioral analysis to catch them.
Finally, these metrics are not enough for ad fraud detection. Bot clicks on ads often happen in the background, without loading your site fully. They may not generate server requests at all. To detect ad fraud, you need client-side tracking that captures mouse movements, scroll behavior, and timing. That is why tools like BotRefund use a combination of server-side and client-side signals.
Real-World Scenarios
Consider an e-commerce site that sees a sudden spike in request volume during a flash sale. The latency rises, but error rates stay normal. This is likely legitimate traffic. The monitoring system should not block it. Instead, it should scale up resources.
Now consider a site that sees a steady increase in 404 errors from a single IP range. The requests are hitting random URLs like /wp-admin, /admin, /login. This is a bot scanning for vulnerabilities. The error rate threshold triggers an alert. The system blocks the IP range and prevents further scanning.
Another scenario: a news site notices that its average session duration has dropped from 3 minutes to 30 seconds. The request volume is normal, but the behavior is unnatural. Users are not scrolling or clicking. This could be a bot that loads pages but does not interact. Behavioral checks like absence of clicks or scrolling would flag this.
Ad fraud is a common scenario. A business runs Google Ads and sees a high click-through rate but zero conversions. The clicks come from suspicious sources with superhuman input speeds and robotic mouse movements. A tool like BotRefund can capture video proof of these bot clicks, then negotiate with Google and Meta for a refund. Bot clicks can steal up to 20% of your ad budget, so catching them in real time is critical.
Comparing Monitoring Approaches
There are several ways to monitor bots in real time. The simplest is to use your web server logs and analytics tools. This gives you request volume, latency, and error rates, but no behavioral data. It is cheap but limited.
Next are dedicated bot management services like Cloudflare Bot Management, Imperva, or Akamai. These use machine learning and behavioral analysis. They can block bots in real time, but they can be expensive and may require configuration.
For ad fraud specifically, specialized tools like BotRefund focus on detecting bot clicks and recovering ad spend. They use a large set of independent checks, including ghost clicks, honeypot traps, and superhuman input speed. They also provide evidence for refund claims.
When choosing a monitoring approach, consider your budget, technical expertise, and specific threats. A small blog might only need basic analytics. An e-commerce site with high ad spend should invest in a comprehensive solution. Always test the tool on your own traffic to ensure it does not block real users.
FAQ: Monitoring Bot Traffic
- Why does my bot traffic spike at night? Bots often operate on automated schedules. If you see spikes during off-hours, it is likely a script running on a server rather than a human user.
- What is a "honeypot" in bot monitoring? A honeypot is a hidden page element that a human would never see or interact with. If a visitor interacts with it, you can be almost certain it is a bot.
- How do I know if my ad spend is being wasted? Look for a high volume of traffic with unnatural session durations—either extremely short or perfectly uniform—that results in zero conversions.
- Does bot protection slow down my site? High-quality protection should be lightweight. If your detection tool adds significant latency, it may be doing more harm than good.
- What is a ghost click? A ghost click is a click event that occurs without the natural sequence of human intent, such as a click that happens instantly after page load or without any preceding mouse movement.
- How many checks does a reliable bot detection system use? Some systems, like BotRefund, use 106 independent checks. The more checks, the better the accuracy, because each check adds corroborating evidence.
- Can a bot mimic human behavior perfectly? It is very difficult. Humans have natural jitter, hesitation, and varied timing. Bots tend to be too precise or too uniform. That is why behavioral signals are powerful.
Further reading and comparison sources
These external sources provide additional context for evaluating the topic. Their inclusion is not an endorsement.
Learn more
Visit the website for more information.