Your Odoo website is sluggish, scheduled actions start late, Odoo.sh restarts workers, and yet nobody changed anything. Often the culprit shows up nowhere in Odoo: it is a bot loading the same public pages tens of thousands of times a day. Here is how to spot it, what it really costs (figures measured in production), and how to stop it on Odoo.sh, where you have neither nginx nor a firewall.
1. A problem the interface never shows
A bot creates no user, no record and no error. It simply calls a few public pages in a loop: appointment booking, the shop, search. Each call costs the server a full page: session, routing, database queries, rendering.
You only see the symptoms: a slow website in quiet hours as well as busy ones, scheduled actions waiting their turn, workers killed for lack of memory, and the temptation to move to a more expensive Odoo.sh plan… which fixes nothing, since the bot will take the extra capacity too.
Price scrapers, booking bots and, lately, AI crawlers (GPTBot, ClaudeBot, Bytespider…) all follow the same pattern: many requests, each of them fast, from a handful of addresses or a single network range.
💡 Key takeaway
A bot is not slow, it is numerous. You will not find it by profiling a page: you have to rank the server logs by cumulative time, URL by URL.
2. A real case: up to 77% of the server for a single bot
On a production Odoo.sh database we maintain, ranking one day of logs gave a clear answer: 175,000 requests a day on the appointment booking pages, for about fifty real appointments. They came from some sixty addresses in the same network range, without reverse DNS (legitimate search engines have one), at a constant rate, 4 a.m. included.
Each request took only about thirty milliseconds. But at that volume, the bot used between 61% and 77% of the server time depending on the day. We blocked it at the very first step of Odoo’s request cycle, then compared two equivalent days (the same weekday, before and after):
- server time used by the bot: −96%;
- total server time: −63%;
- saturated minutes: from 50 to 5;
- workers killed by the system: from 12 to 0.
A trade-off worth stating plainly: the response time of a page for a human visitor did not go down (88.6 ms before, 91.3 ms after). The gain is in freed capacity and the end of saturation peaks, not in the speed of each page.
💡 Key takeaway
Blocking a bot does not make a page faster. It gives the server back the hours of computing it was wasting, and ends the peaks that brought workers down.
3. On Odoo.sh, no nginx and no firewall
On your own server, you block a bot with an nginx rule or a firewall line. On Odoo.sh you have access to neither: everything that reaches your domain is served by Odoo.
If your domain goes through Cloudflare and you can configure its firewall (WAF), that is the best option: the bot is stopped before it even reaches Odoo. But many installations cannot do that, and the bots that still get through need handling. The protection then has to live inside Odoo, at the earliest possible point.
💡 Key takeaway
Block upstream (Cloudflare) when you can, inside Odoo otherwise. The two complement each other.
4. Anti-Bot Rate Limiter: the same method, as a module
We turned this case into a module, available on the Odoo Apps Store for Odoo 18, 19 and 20 (Community and Enterprise, €49). It checks each request before authentication, routing and rendering:
- rules per URL (
/appointment*,/shop*…), per method and per User-Agent, with a limit over a sliding window; - counting per address or per network (/24 in IPv4, /64 in IPv6): a bot rotating over a whole range is seen as one;
- an Observe mode, which counts what would be refused without refusing anything, then a Block mode: a “429 Too Many Requests” response and a temporary ban of the network;
- lists of always-allowed networks (your offices, your partners) or blocked ones;
- a traffic report per address and per hour, with one-click blocking.
What mattered most to us: no database query per visit. Each worker counts in memory and shares its counters with the others every 5 seconds, in a single batch (every second during an attack). A protection that slowed down every page would not be one. see the module page
💡 Key takeaway
Counting per network rather than per address is what makes the difference against a bot spread over dozens of IPs.
5. Rolling it out without blocking your customers
Every rule shipped starts in Observe mode: installing refuses nothing. Let it run for a day, read the traffic report, then switch to Block only the rules you are sure about. Logged-in users and private addresses (office network, proxy) are never counted, and when in doubt, the module lets the request through.
Google and the search engines are not targeted by the default rules. And a “429” is understood by them as “slow down”, not as an error.
💡 Key takeaway
Observe first, block second: you only block what the figures have shown.
⚔️ The Match: Odoo alone vs Anti-Bot Rate Limiter
| Criterion | Odoo alone | With the module |
|---|---|---|
| Cost of a bot request | A full page (≈ 26 ms) | A refusal (≈ 3 ms) |
| Bot spread over a range | Invisible | Counted per /24 network |
| Works on Odoo.sh | — | Yes, without nginx |
| See who loads the server | Raw logs to analyse | Report per address and per hour |
| Risk-free rollout | — | Observe mode |
Per-request costs measured on the Odoo.sh production logs of the case described above, over two comparable days (same weekday), before and after blocking.
The Verdict: before paying for more server, check who is using it
A slow Odoo does not always need more power. Sometimes it needs to lose a visitor who never buys anything. The module is on the Odoo Apps Store for
Odoo 18,
Odoo 19 and
Odoo 20.
Not sure what is slowing your Odoo down? We rank your logs and tell you where the server time goes, during an
audit of your Odoo.
Your Odoo website is sluggish, scheduled actions start late, Odoo.sh restarts workers, and yet nobody changed anything. Often the culprit shows up nowhere in Odoo: it is a bot loading the same public pages tens of thousands of times a day. Here is how to spot it, what it really costs (figures measured in production), and how to stop it on Odoo.sh, where you have neither nginx nor a firewall.
1. A problem the interface never shows
A bot creates no user, no record and no error. It simply calls a few public pages in a loop: appointment booking, the shop, search. Each call costs the server a full page: session, routing, database queries, rendering.
You only see the symptoms: a slow website in quiet hours as well as busy ones, scheduled actions waiting their turn, workers killed for lack of memory, and the temptation to move to a more expensive Odoo.sh plan… which fixes nothing, since the bot will take the extra capacity too.
Price scrapers, booking bots and, lately, AI crawlers (GPTBot, ClaudeBot, Bytespider…) all follow the same pattern: many requests, each of them fast, from a handful of addresses or a single network range.
💡 Key takeaway
A bot is not slow, it is numerous. You will not find it by profiling a page: you have to rank the server logs by cumulative time, URL by URL.
2. A real case: up to 77% of the server for a single bot
On a production Odoo.sh database we maintain, ranking one day of logs gave a clear answer: 175,000 requests a day on the appointment booking pages, for about fifty real appointments. They came from some sixty addresses in the same network range, without reverse DNS (legitimate search engines have one), at a constant rate, 4 a.m. included.
Each request took only about thirty milliseconds. But at that volume, the bot used between 61% and 77% of the server time depending on the day. We blocked it at the very first step of Odoo’s request cycle, then compared two equivalent days (the same weekday, before and after):
- server time used by the bot: −96%;
- total server time: −63%;
- saturated minutes: from 50 to 5;
- workers killed by the system: from 12 to 0.
A trade-off worth stating plainly: the response time of a page for a human visitor did not go down (88.6 ms before, 91.3 ms after). The gain is in freed capacity and the end of saturation peaks, not in the speed of each page.
💡 Key takeaway
Blocking a bot does not make a page faster. It gives the server back the hours of computing it was wasting, and ends the peaks that brought workers down.
3. On Odoo.sh, no nginx and no firewall
On your own server, you block a bot with an nginx rule or a firewall line. On Odoo.sh you have access to neither: everything that reaches your domain is served by Odoo.
If your domain goes through Cloudflare and you can configure its firewall (WAF), that is the best option: the bot is stopped before it even reaches Odoo. But many installations cannot do that, and the bots that still get through need handling. The protection then has to live inside Odoo, at the earliest possible point.
💡 Key takeaway
Block upstream (Cloudflare) when you can, inside Odoo otherwise. The two complement each other.
4. Anti-Bot Rate Limiter: the same method, as a module
We turned this case into a module, available on the Odoo Apps Store for Odoo 18, 19 and 20 (Community and Enterprise, €49). It checks each request before authentication, routing and rendering:
- rules per URL (
/appointment*,/shop*…), per method and per User-Agent, with a limit over a sliding window; - counting per address or per network (/24 in IPv4, /64 in IPv6): a bot rotating over a whole range is seen as one;
- an Observe mode, which counts what would be refused without refusing anything, then a Block mode: a “429 Too Many Requests” response and a temporary ban of the network;
- lists of always-allowed networks (your offices, your partners) or blocked ones;
- a traffic report per address and per hour, with one-click blocking.
What mattered most to us: no database query per visit. Each worker counts in memory and shares its counters with the others every 5 seconds, in a single batch (every second during an attack). A protection that slowed down every page would not be one. see the module page
💡 Key takeaway
Counting per network rather than per address is what makes the difference against a bot spread over dozens of IPs.
5. Rolling it out without blocking your customers
Every rule shipped starts in Observe mode: installing refuses nothing. Let it run for a day, read the traffic report, then switch to Block only the rules you are sure about. Logged-in users and private addresses (office network, proxy) are never counted, and when in doubt, the module lets the request through.
Google and the search engines are not targeted by the default rules. And a “429” is understood by them as “slow down”, not as an error.
💡 Key takeaway
Observe first, block second: you only block what the figures have shown.
⚔️ The Match: Odoo alone vs Anti-Bot Rate Limiter
| Criterion | Odoo alone | With the module |
|---|---|---|
| Cost of a bot request | A full page (≈ 26 ms) | A refusal (≈ 3 ms) |
| Bot spread over a range | Invisible | Counted per /24 network |
| Works on Odoo.sh | — | Yes, without nginx |
| See who loads the server | Raw logs to analyse | Report per address and per hour |
| Risk-free rollout | — | Observe mode |
Per-request costs measured on the Odoo.sh production logs of the case described above, over two comparable days (same weekday), before and after blocking.
The Verdict: before paying for more server, check who is using it
A slow Odoo does not always need more power. Sometimes it needs to lose a visitor who never buys anything. The module is on the Odoo Apps Store for
Odoo 18,
Odoo 19 and
Odoo 20.
Not sure what is slowing your Odoo down? We rank your logs and tell you where the server time goes, during an
audit of your Odoo.