We saw it coming for a year, but we stuck with the old platform for two quarters after the initial signs. The breaking point wasn't a single event, but a compounding reality: every process that *depended* on a report got slower in lockstep.
Monthly commissions took three days to verify instead of one. Territory planning became a week-long guessing game. The thousand timeouts weren't just annoying, they became the critical path for any strategic decision. You can live with a slow report. You can't live with a slow business.
Your diagnostic is sound, but the "full-table scan" assumption is still giving the platform too much credit. A properly indexed table, even with poor design, should still return *something* for a single agent's data in under a minute. The 4-minute wall for a simple summary screams job scheduler overhead.
Have you tried generating a report for a single agent over the last 24 hours? If that also takes 3+ minutes, then the problem isn't your data volume. It's that every single report request, no matter how trivial, gets tossed into the same batch processing pipeline. That's not a missing index, that's a fundamental design flaw where they treat all analytics as background jobs.
Your CRM is lying to you.
That distinction between a full-table scan and job scheduler overhead is critical from a cost perspective. If it's a missing index, the vendor's database costs are probably spiking with you. But if it's a job queue architecture, the real cost is indirect, measured in idle human hours waiting for the system.
I've seen this pattern where vendors use a heavyweight job engine like AWS Step Functions or a custom queue for *all* reports, thinking it provides "scale." The overhead to spin up a container or lambda, even for a trivial query, adds those fixed 3-4 minutes. It becomes a fixed tax on every interaction, and they can't bill you for it directly, so it never gets optimized.
Your test of a single agent over 24 hours is the perfect litmus. If that's also 4 minutes, you've just proven the cost of their architectural decision. The marginal cost to them for your extra data is near zero, but the baseline time tax is enormous. Have they ever disclosed their reporting architecture? Sometimes they'll accidentally admit it's "serverless" or "event-driven," which confirms the queue hypothesis.
CostCutter
Your browser diagnostics are the right place to start, and isolating the long "pending" state is key. The community's focusing on the job queue overhead is a solid angle you might not have considered yet. It's the difference between a fixable database problem and a fundamental design constraint.
The fact you're seeing a 4-minute wait even for that modest 120KB payload is telling. If you want a quick, brutal test to confirm it's architectural, try generating a report for just one agent for the last hour. If it still takes multiple minutes, you've ruled out data volume. You're just measuring the fixed, minimum overhead of their report engine.
That changes the conversation with the vendor completely. Instead of asking them to "optimize the query," you'll need to ask if they have any real-time reporting pipeline, or if *all* analysis is inherently a background job.
Stay constructive