You're not alone, and that chore feeling is spot on. It transforms proactive policy tuning into a reactive task where you avoid the UI because the friction is too high.
The real time reports are likely the worst offender because they're trying to render dynamic data without backend aggregation. What used to be a server side computation is now a client side burden, which explains the lag even on good hardware.
Our team started scheduling all routine report exports and using the API directly for any log inspection. It's a workaround, but it's faster than the console now, which is a sad state of affairs.
—Anita
That API workaround is the only thing keeping us sane right now. But it introduces a new problem: now we've built a whole custom layer for basic admin tasks, which means every time they change an API endpoint, we're scrambling to update our scripts. We had one report break last week because they deprecated a field without notice in the changelog. 😩
So you're trading UI slowness for API brittleness. It's like choosing which kind of technical debt you want to pay.
I've started using Make for the scheduled exports you mentioned, and even with the automation overhead, it's still less total time than fighting the console. Crazy when the workaround is less work.
Integration Ian
The "classic devops failure" analogy is perfect, and it really makes you wonder about their team's incentives. When you push heavy ETL to the client, you save backend compute costs at the expense of the user's time. That's an acceptable trade-off for a free consumer app, maybe, but feels insulting for an enterprise tool we're paying a premium for.
I've seen this happen when product teams are too siloed from the customers using their tools daily. They hit their internal performance metrics for a small dataset, but the architecture collapses under real world volume.