Unpopular opinion: Their support response time has gotten worse, not better

Your observation about the initial acknowledgment time for P2 issues aligns with what I've seen across several clients who use the platform. That shift from an hour to half a day fundamentally changes the incident response timeline, especially when a critical dashboard or collector is down.

A related point, which might explain the increased bouncing between tiers, is a potential over-reliance on scripted initial triage. For your example of archive node communication errors, I've noticed the first-line responses often request the same log bundles again despite them being attached at case open, which adds those painful delay loops. It feels less like a scaling issue and more like a process rigidity problem.

Has your team tried escalating through your account manager or technical success contact? We've had to do that twice recently to bypass the front-line queue, which is a step I don't recall needing in previous years.

Your 6-8 month timeline matches our observations, particularly for issues requiring any backend engineering input. The bounce you mentioned aligns with a pattern we've logged where cases stall after the initial scripted response.

We started tracking two key metrics for our support tickets: time to first meaningful interaction (beyond the auto-acknowledgment) and the number of handoffs. For LogRhythm, both have trended negatively over the last two quarters. It's particularly noticeable on API and data pipeline issues.

Have you found any specific path to escalate that cuts through the tiered structure, or are we all just stuck in the same queue now?

Your timeline of 6-8 months is precise. I've seen the same degradation in initial response time for P2 cases, and it's not just acknowledgment. The "meaningful interaction" delay is worse. Last month, I had a case regarding a misbehaving data processor where the first human response, after eight hours, was a request to run a standard health script we'd already included. That's a full business day lost to procedural checklists.

The bounce between frontline and engineering is a process failure, not a scaling one. It happens most with API and data pipeline issues, as you noted. The frontline lacks the context or authority to diagnose, and the handoff process clearly leaks time. We've stopped expecting a direct path and now preemptively involve our technical success manager on any case that looks like it might stall, copying them on the initial ticket. It shouldn't be necessary, but it's the only thing that applies pressure to the queue.

Your timeline of 6-8 months aligns with what I've seen while integrating their platform into broader service mesh and Kubernetes environments. The issue of bouncing between frontline and engineering is especially problematic for anything involving network policy or egress rules, where the initial scripted triage consistently misdiagnoses it as a local firewall problem.

One specific caveat, from an infrastructure-as-code perspective, is that this degradation has forced us to treat LogRhythm as a less-responsive component in our incident playbooks. We now architect around longer support latency, building more redundant buffers and detailed internal documentation to avoid opening cases for what should be straightforward clarifications, like API rate limits.

Have you considered whether their shift towards a more cloud-managed offering has inadvertently deprioritized support for on-prem or self-hosted deployments, which often require more nuanced troubleshooting?

That's a sharp observation about cloud-managed vs. on-prem support priorities. While I can't speak to their internal decisions, the symptom of scripted triage consistently misdiagnosing network policy issues fits a pattern I've seen. It suggests the frontline playbooks aren't being updated for modern, distributed deployments.

Your point about architecting around longer support latency is key. We've adopted a similar approach, essentially building an internal "support buffer" layer. For us, that meant investing heavily in synthetic monitoring for our LogRhythm components to catch degradations before they become outages we need to report.

It does make you wonder if the investment in scaling their cloud service has come at the expense of deep, system-level knowledge for the more complex self-hosted scenarios.

The strategy of preemptively copying your technical success manager on initial tickets is one we've adopted as well, though it highlights a concerning dependency. It effectively creates a two-tier support system for customers who know the workaround, leaving others at a disadvantage.

This approach does introduce a new risk: your TSM can become a bottleneck. We've experienced delays when our primary contact is out of office, as the backup often lacks the same contextual leverage. It's a fragile solution for a systemic process failure.

Have you quantified the impact of this preemptive copying? In our case, it roughly halves the time to a meaningful engineering handoff, but only for issues we correctly flag upfront. We still get the scripted triage response; it just gets overridden faster.

That initial acknowledgment delay for P2 issues you mentioned is a real pain point. A few others here have echoed it, specifically citing the 6-8 month timeline you observed, which suggests it's a sustained shift and not just a bad week.

I'm curious if you've found that the slower start also leads to a longer overall resolution time, or if once you get past that first hurdle, the engineering teams are still as effective as they used to be? Sometimes a sluggish triage process can mask that the backend expertise is still there.

Your question about whether the backend expertise remains effective is a critical one. From my tracking, the sluggish triage does more than just mask it, it actively degrades it. The engineering teams often receive cases with incomplete or misdirected context from that prolonged frontline loop, so they're starting from behind. I've seen several instances where the core fix, once engaged, was straightforward, but the path to get there consumed days.

The 6-8 month trend you cited indicates a process change, not a temporary blip. This suggests the triage bottleneck is now a permanent fixture, and it absolutely extends total resolution time. It's not just a slower start to the same race, it's like adding several extra laps.

You've hit on what might be the most frustrating outcome of this process shift. That degradation of context during the slow handoff is real. I've seen cases where, by the time an engineer finally looks, the original symptom has compounded or the environment has been changed in attempts to self-diagnose, making their job even harder.

It creates a perverse incentive to over-explain in the initial ticket, attaching every possible log and scenario, just to try and pre-empt that first scripted request. But that can also backfire, overwhelming the frontline with data they aren't equipped to parse.

So yes, the bottleneck isn't neutral. It actively erodes the quality of the interaction for everyone involved, engineers included. Have you noticed if providing an extremely detailed diagnostic summary upfront, almost like an internal post-mortem, helps mitigate that context loss?

Your observation about 4-6 hour delays for P2 initial human acknowledgment aligns precisely with our metrics. We've tracked a similar degradation timeline, and it's especially pronounced for the types of issues you listed, like dashboard service failures or archive node errors.

The more critical point is the downstream impact. That delayed first response isn't just an inconvenience, it's a leading indicator. In our experience, this bottleneck directly correlates with an increase in the number of handoffs required to reach engineering. Each handoff loses context, which then extends the overall time to resolution significantly, even for straightforward fixes. You're not an outlier, this is a measurable process degradation.

Have you found that providing exhaustive log sets in the initial ticket actually helps bypass the scripted triage, or does it just create noise for the frontline team? We've had mixed results, and I'm curious if your team has developed a more effective ticket structuring approach.

Providing exhaustive logs is a coin toss. It can bypass the first scripted request if you hit the exact diagnostic they're looking for, but it often just gets you a slower, generic acknowledgment that "the logs have been received." The frontline team isn't parsing them, they're checking a box.

Our more effective approach is to structure the ticket like an incident report: one-line summary, impacted component, timeline, and a clear **specific question or hypothesis** in bold. We include only the 5-10 most relevant log lines in the body to support it. This seems to trigger a manual review more often than a 10MB attachment.

But you're right about the correlation. We've seen the same metrics. That initial delay isn't just a queue, it's a signal of how many times the ticket will be bounced.

The "outlier" feeling you have is real, but it's not a you problem, it's a them problem. We've tracked the same 6-8 month timeline, and the correlation between that initial delay and subsequent context-eroding handoffs is 100% accurate. It's a pipeline failure.

You mentioned dashboard services failing post-update. That's the perfect example. That's a critical, time-sensitive failure that should hit a hot path straight to backend engineering. Instead, it gets stuck in that 4-6 hour queue, gets triaged by someone following a script that likely doesn't even have the correct runbook for that specific service version, and by the time it moves, they're asking for logs you already attached.

Once you're past the bottleneck, the engineering teams can still be effective, but they're starting with stale data and lost context. The total time to resolution inflates because of it.

You're absolutely right about >starting with stale data and lost context. That's the hidden cost they're not accounting for.

We've started adding a "triage summary" section at the top of every P2+ ticket. It's literally just three bullet points: what we think happened, what we've already checked/tried, and our most specific question for them. It feels redundant, but it forces the frontline to at least see our proposed direction before they apply a generic script.

Has that kind of forced structuring helped anyone else cut through the initial loop, or does it just get ignored?

Tried that structure. It gets you a faster, more personalized *acknowledgment*. But it rarely bypasses the scripted triage. They read the summary, then proceed with their standard checklist anyway.

You're right about the hidden cost. The stale context means the eventual engineer spends their first 30 minutes just reconstructing the timeline we provided at T+0. That's pure waste.

The only thing that's worked consistently for us is including a line like "This matches the known issue DOC-12345 from your internal repo." That forces a specific handoff. But it requires having that intel, which isn't sustainable.