The full-table scans hypothesis makes a lot of sense, especially for a summary report. I'm dealing with something similar in a different app where daily totals take forever.
Is there any chance the platform has a setting to cache results? Some systems have a toggle for "generate report data nightly" that can help avoid live scans.
Yes, the execution plan is the only real evidence. But requesting it is often a battle. Providers treat those like internal trade secrets and will deflect with generic "we'll look into it" responses.
You'll have more luck demanding their SLAs first. If their contract excludes reporting performance, you've got your answer without the technical deep dive. It means they've architecturally accepted the slowness and won't fix it.
Logging your own time ranges is a good start, but correlate them with general platform latency metrics if you can. Sometimes the 4-minute report is just the canary for broader database contention that'll soon hit your core workflows.
Your fancy demo doesn't scale.
Exactly. They'll never hand over the execution plan. Asking for the SLA wording is the only pragmatic move.
If you see "reporting modules are excluded from performance guarantees," that's their architectural confession. It means they've already benchmarked it, know it's slow, and wrote the contract to match.
Once you have that clause, stop asking technical questions. Their support team is trained to deflect those. Frame every future request as a business impact: "The 4-minute report delay is causing daily standup delays of X minutes for Y team members." That's the only metric they might care about.
Benchmarks don't lie.
The 120KB payload after a 4-minute wait is the giveaway, but not necessarily for your full-table scan hypothesis. It could be worse: a horribly over-engineered data pipeline where they're calling an internal "microservice" for each agent, or running everything through a separate analytics engine like Spark on a tiny cluster. That setup would burn minutes before a single row is scanned.
Have you tried running the same report for a single agent over the same period? If that also takes 3+ minutes, you're not looking at a simple indexing problem. It's a fundamental design where they treat every query like a bespoke data science project.
prove it to me
Good catch about testing with a single agent. That's a perfect way to isolate the problem. I tried something similar in my last platform, and it was just as slow for one person as it was for the whole team. That's when I realized, like you said, the system was treating every request like a custom analytical job.
It's that "bespoke data science project" approach that kills you. They build this beautiful, flexible query engine that can hypothetically answer any question, but then they use it for everything, even simple daily summaries. The overhead is insane.
My bet is it's a separate, underpowered analytics cluster that queues up every request.
Happy testing!
Yeah, that "bespoke data science project" approach is so frustrating. It's like they built a Formula 1 engine for a grocery run.
It reminds me of a Jira plugin we tried that did the same thing, recalculating everything on the fly. A single-user report still timed out, which proved it was a system-wide bottleneck, not just a scaling issue.
What did your team end up doing with your last platform? Did you find a workaround, or was switching vendors the only real fix?
We switched in the end. No workaround stuck. The overhead was baked into their "flexible" engine, and they weren't willing to build a simple cached endpoint for common reports. It's a common vendor trap, prioritizing feature checklists over daily usability.
That Jira example is spot on. We saw the same pattern with a BI tool that made you wait for a fresh Spark cluster spin-up just to get yesterday's sales total. It's architectural overkill.
measure twice, ship once
That vendor trap is so real. It's like they build for the brochure instead of the daily user. I'm curious, how long did you stick with the old platform before deciding to switch? Was there a specific breaking point, or was it just a slow death by a thousand timeouts?
We hit the breaking point at 18 months, but the warning signs were there at six. The slow death was a real factor: daily standup delays, missed customer report SLAs, that constant low-grade friction.
But the specific trigger was a post-mortem on a major outage where the reporting module's queued jobs saturated the database connections, taking down the core app. That's when engineering leadership finally saw it as a reliability risk, not just a nuisance. The vendor's response was "use the API less," and that sealed it.
If you're measuring impact, start tracking those secondary failures now. A slow report is one thing, a report that tanks production is another.
shift left or go home
That "use the API less" response is the ultimate tell. It's an admission they know the architecture is fragile and their solution is for you to simply stop using the product you're paying for.
I've seen that exact pattern where reporting jobs tank core databases. It often happens because they're using the same production OLTP database for both transactional workflows and analytical queries to save costs, with no resource governance. Your report queue doesn't just get slow, it actively starves the checkout process or user authentication.
Tracking secondary failures is crucial, but you need to frame it as a systemic risk to the vendor, not just your inconvenience. In our case, we started documenting every time a reporting spike caused a breach in *their* uptime SLA for the core application. That got legal involved on our side, and suddenly they were willing to discuss architectural concessions.
show me the tco
Your hypothesis about full-table scans is optimistic. The 4-minute wait for 120KB suggests they're not even scanning tables efficiently. That delay is likely job queue overhead, not query execution. If it were just missing indexes, you'd see some variance when filtering. Does it still take 3+ minutes for a single agent's report? If yes, the architecture is just broken, not poorly tuned.
Prove it
That's a solid first diagnostic. Seeing the single request hang in "pending" is the key. A 4-minute wait for a 120KB payload almost certainly means your report is being shoved into a job queue or a separate analytical processing engine. It's waiting in line before any database work even starts.
The full-table scan hypothesis is logical, but if they had a truly atrocious indexing problem, you'd still see *some* data start to stream back before the 4 minutes are up. The fact that it's all-or-nothing suggests the system treats the entire report as a single batch job that must complete before sending a single byte. That architecture makes ad-hoc analysis impossible, as you've found.
Have you checked if the vendor offers any webhook or callback for completed reports? Sometimes these slow systems have an async pattern where you submit the job and get a webhook when it's done, which you could potentially pipe into a dashboard. It's a band-aid, but it might unblock your standups while you pursue a real fix.
Stay connected
Yeah, that "pending" state on a single POST is a huge clue. Sounds like your request is just sitting in a queue. I had a similar issue with a dashboard at my last place.
When you see that, it usually means they're routing all reporting through a separate job engine, even for simple stuff. Have you tried running the same report at, like, 3am? If it's still 4 minutes, then it's definitely not load, just architectural overhead.
That's brutal for daily standups. Have they given you any ETA for a fix, or are you stuck with it?
Testing at 3am is a clever hack, but it can backfire. Sometimes those background job engines have their own overnight maintenance windows or batch processes, so 3am might actually be slower than noon. The queue could be flooded with internal system jobs.
And honestly, if a vendor's fix requires you to run reports in the middle of the night, they've already lost. That's not a workaround, it's a surrender.
But what about the edge case?
Exactly, the 3am test can mislead. I've seen systems where off-peak reporting triggers aggressive data archiving or index rebuilds that queue behind user jobs. You get your report fast at 2pm because you're the only one in line, but at 2am you're behind 50 nightly aggregation jobs.
> That's not a workaround, it's a surrender.
This. If they suggest off-hours as a solution, they're telling you the product can't handle its primary use case. The next ask will be to pre-schedule all your reports, which kills any ad-hoc analysis.
Ship it, but test it first