[BUG] Report page freezes the entire UI

[Lixeas]

What happened?

In addition to having the same issue as #3683

When I open the Report page, it loads, displays “Processing…”, and then remains stuck on that screen. Whether or not there is a filter. It even becomes impossible to change pages. Forcing a refresh doesn’t change anything, and neither does editing the URL to go to /home.
I have to close the tab and reopen it. I’d like to point out that all the other pages work fine.
I updated from 1.6.9 to 1.6.11 on June 30, 2026. Before that, there were no issues. In the container resource usage stats, there is no excessive CPU or RAM usage.

Additionally, on July 1, 2026, all the statics and reports were completely cleared out “for no reason.”

How to reproduce?

Navigate to /reports

Configuration file(s) (yaml or .env)

Service in Docker Compose:

  redis:
    image: redis:8-alpine
    command: >
      redis-server
      --maxmemory 2gb
      --maxmemory-policy allkeys-lru
      --save 60 1000
      --appendonly yes
    volumes:
      - /home/_Dockers/bunkerweb/data-redis:/data
    restart: "unless-stopped"
    networks:
      - bw-universe

Relevant log output

BunkerWeb version

1.6.11

What integration are you using?

Docker

Linux distribution (if applicable)

Ubuntun Server 24.04

Removed private data

• I have removed all private data from the configuration file and the logs

Code of Conduct

• I agree to follow this project's Code of Conduct

[TheophileDiot]

Hi @Lixeas, thanks for the report. There are two separate things tangled together here, so let me split them.

The cleared reports and stats are almost certainly your Redis eviction policy. BunkerWeb keeps blocked-request reports, and the aggregates that feed the Reports page, in Redis as keys that have no TTL. Your Redis is started with --maxmemory-policy allkeys-lru, which lets Redis delete any key once it hits maxmemory 2gb, whether that key has an expiry or not. The policy we recommend is volatile-lru, because with that one only keys that actually have a TTL get evicted, so your report data (and your permanent bans, which also have no TTL) are safe. allkeys-lru really only fits a Redis you're treating as a throwaway cache, and nothing dropping "for no reason" is exactly what it looks like when it evicts data BunkerWeb expected to still be there.

Can you switch the policy to:

--maxmemory-policy volatile-lru

(or noeviction if you'd rather a write fail than have data silently dropped), and while you're at it make sure maxmemory is comfortably above what your dataset actually needs. If you can give BunkerWeb its own Redis database rather than sharing those 2 GB with other things, even better.

Before you change anything though, it'd really help to confirm this is what happened. Could you grab:

redis-cli INFO stats | grep evicted_keys
redis-cli INFO memory | grep -E 'used_memory:|maxmemory:'
redis-cli EXISTS requests requests:facets:initialized
redis-cli LLEN requests
redis-cli HLEN requests:facet:ip

If evicted_keys comes back above 0, that's basically the confirmation. Once you've switched the policy, running redis-cli DEL requests:facets:initialized lets the aggregates rebuild cleanly on the next metrics cycle.

The page freezing the whole tab looks like a separate issue, and that one's on us. A slow or stuck request shouldn't be able to lock the tab up the way you're describing, so I want to pin down where it's actually getting stuck. Next time it hangs on "Processing...", two things would help:

1. Open your browser dev tools, go to the Network tab, reload /reports, and tell me which request just sits there pending and never finishes, /reports/fetch or /reports/filters. And check the Console tab for any red errors while you're there.
2. Let me know whether it still freezes at the default page size (10 rows) or only once you've bumped it up to something like 500 or 1000, and what you've got METRICS_MAX_BLOCKED_REQUESTS_REDIS set to.

That tells me whether it's the query on the server side or the table rendering in the browser. Either way, we've already spotted a couple of rough edges in the reports table (no timeout on the request, and a row highlight that gets expensive at large page sizes) that we'll tidy up regardless.

This one's unrelated to #3683, we're tracking that one separately.