I've been running Panther in production for about nine months now, primarily for log analysis and security alerting on our Kubernetes clusters. Overall, the platform's correlation engine is solid, but I'm hitting a critical and frankly baffling UI/UX issue that's grinding my team's workflow to a halt.
Whenever we attempt to execute a search query in the Data Explorer that spans more than 30 days of log data, the web UI becomes completely unresponsive. The browser tab freezes for 45-90 seconds before either timing out or finally returning a subset of results. This isn't just a "spinner" or a slow query—it's a full UI lock-up where you can't interact with any other part of the Panther interface. This makes exploratory analysis over quarterly data or investigating slow-moving security incidents practically impossible through the GUI.
Here’s a breakdown of my environment and what I've isolated so far:
**Environment:**
* Panther v1.21 (SaaS-hosted instance)
* Data Lake: AWS S3 (parquet formatted logs, ~8TB total)
* Primary Source: EKS audit logs, CloudTrail, VPC Flow Logs
* Query Pattern: Simple `SELECT` with `WHERE` time filters and `LIKE` or regex operations.
**Example of a problematic query:**
```sql
SELECT p_event_time, p_source_id, eventName, userIdentity.arn
FROM panther_logs.public.main
WHERE p_occurs_since('90 days')
AND eventName LIKE '%Delete%'
AND source = 'aws.cloudtrail'
ORDER BY p_event_time DESC
LIMIT 1000
```
Reducing the timeframe to `p_occurs_since('29 days')` executes in 3-4 seconds with no UI freeze. The moment I cross that ~30-day threshold, the lock-up occurs.
**My hypotheses and what I've ruled out:**
1. **Client-side resource exhaustion:** Browser memory/CPU is fine. This happens across Chrome, Firefox, and on different machines.
2. **Network payload size:** We're using `LIMIT 1000`, so the result set isn't the issue. The freeze happens *during* query execution, not during rendering.
3. **Athena/Spark query performance:** I've run similar queries directly in Athena. While they take longer (20-30 seconds for 90 days), they don't time out. This suggests the issue is in Panther's UI backend or the middleware that manages the query session.
This feels like a frontend or API gateway timeout configuration that isn't handling long-running queries gracefully, perhaps failing to yield the main thread. It's a significant pitfall for a product built on a data lake paradigm, where analyzing historical data is a core use case.
Has anyone else encountered this? Is there a known workaround or configuration parameter (server-side or client-side) to adjust timeouts or query execution behavior? I'm about to open a support ticket, but I'm curious if the community has already reverse-engineered the problem.
-- alex
> "the web UI becomes completely unresponsive"
This is almost certainly a client-side rendering issue, not a backend query timeout. Panther's Data Explorer fetches results into the browser's memory. If your query returns a large result set (thousands of rows with wide columns) the browser's DOM or the frontend framework trying to render a virtual grid will lock up. I've seen this with Snowflake and Athena-based tools too.
Check the actual row count returned. If it's > 10k rows, try adding `LIMIT 1000` to your query and see if the UI stays responsive. The 45-90 second freeze matches the time it takes to parse and render a multi-MB JSON response.
Separately, on the cost side: scanning 8TB of parquet across 30+ days of EKS audit logs is going to rack up Athena charges fast. You might want to partition your S3 data by day (or even hour) and use partition pruning in your `WHERE` clause. That will shrink the scanned data, speed up the query, and reduce the result set size. The UI freeze is a symptom of a larger data architecture problem.
Right-size or die
user461 is probably half right, but the client-side rendering choke is only a symptom. The root cause is likely that Panther's SaaS frontend is issuing a synchronous HTTP request for that massive query, and the browser's main thread is blocked waiting for the response. It's a terrible architectural pattern for a log analytics UI, but I've seen it before when teams graft a fancy React frontend onto what's essentially a slow, batch-oriented backend.
You can test this by opening your browser's dev tools before running the query, going to the Network tab, and checking if the request type is `XMLHttpRequest` or `fetch` with a synchronous flag. If it is, that's your smoking gun. No amount of `LIMIT` clauses will fix the underlying design flaw, they'll just paper over it until your data volume grows again.
And while we're here, the cost angle is more severe than you think. A UI lock-up often means the backend is still churning through that full scan. Your Athena bill for that 90-second freeze is probably shocking.
Your k8s cluster is 40% idle.
This is super interesting. I'm coming from a project management background, not dev, so the technical side is new to me.
> synchronous HTTP request
I looked up what this means and... ouch. That seems like a really basic thing for a SaaS product to get wrong in 2024. It feels like a bad user experience choice, not just a bug.
Is there a workaround for the original poster, other than just not running those queries? Like, could they use the API directly with a different tool while they wait for a Panther fix?
You've hit on the crucial question: is there a workable path forward while waiting for a potential platform fix? In my experience, the API route you mentioned is often the best temporary escape hatch.
Even if the UI is making a blocking synchronous request, the underlying Panther API endpoints usually respect async patterns. You could script your wide-time-range queries using the CLI or a simple Python script that polls for results. That gets the heavy lifting out of the browser entirely. It's a clunky workaround for an interactive tool, but it can unblock those quarterly investigations.
The other angle, which is less technical but just as important, is raising this with Panther support as a business-impacting UX flaw. Describing it as a workflow blocker for investigating slow-moving incidents puts the right emphasis on it not being a "nice-to-have." Sometimes framing it in terms of a security use case gets a faster response than a generic performance ticket. Have you opened a case with them yet?
Let's keep it real.