I've been a SentinelOne customer for about four years now, and I generally recommend it when folks ask about endpoint protection. The product itself is solid, and it's been a key part of our stack. But I have to raise a concern that's becoming a real operational issue: the support response times have noticeably degraded over the last 12-18 months.
In the early days, opening a critical severity ticket would get a human response within the hour, often with a direct line to an engineer if it was truly blocking. Now? We had a recent incident where a policy push locked up a group of servers—clear critical issue—and it took over four hours just to get the initial "we're looking into it" acknowledgment. That's a dangerous trajectory for a security product.
This isn't just about critical tickets, either. For general technical questions or configuration clarifications, what used to be a same-day or next-day response now routinely slips to 2-3 business days. In the context of a migration or a security audit, those delays add real friction.
I'm wondering if this is a scaling problem. As they've grown, has the support team simply not kept pace? Or has the model changed? We're on a premium plan, and I've double-checked our SLA, but the reality on the ground feels different.
Here's a rough timeline from our last three support cases, for context:
* **Case 1 (Policy Issue, Critical):** Submission -> First response: 4 hours 15 minutes. Total time to resolve: 11 hours.
* **Case 2 (Sensor Update Query, Low):** Submission -> First response: 2 business days. Follow-up replies each took ~24 hours.
* **Case 3 (False Positive Analysis, Medium):** Submission -> First response: 1 business day. Resolution required two follow-ups, each adding a day of waiting.
I'm sharing this not to just vent, but to see if others are experiencing the same trend. For those who have migrated away or are considering it: did support experience factor into your decision? And for long-timers, have you found a way to get better engagement—maybe through your account manager or a different support portal tier?
From my professional standpoint, when you're integrating a tool this deeply into your infrastructure, support responsiveness isn't a luxury; it's a core part of the product's value. I'm starting to weigh that more heavily in our vendor assessments.
-- Mike
Map twice, migrate once.
That's a tough spot, waiting four hours on a critical ticket when systems are locked. I haven't had to call them for anything urgent yet, but hearing this makes me nervous as we're planning to expand our deployment.
You mentioned it might be a scaling issue. I'm curious, has your account team acknowledged the longer wait times at all? Sometimes they'll point to a new support portal or tier system. It feels like a common story when companies grow fast.
One step at a time
Yeah, the four-hour wait on a critical lock-up is really concerning. It makes you question the "critical" SLA definition.
I've seen this scaling pattern before in other martech tools. The initial premium support feels almost like a concierge service, then it normalizes to something much more standard as the customer base grows. I'd be curious if your premium plan actually guarantees a specific response time for critical tickets. Sometimes those contractual details shift quietly.
Have you noticed any difference in the quality of the responses once you finally get them, or is it just the initial delay that's changed? Slower responses I can maybe budget for, but if the solutions are also less thorough, that's a whole different problem.
You've touched on the crucial distinction between initial response time and resolution quality. In our case, both have degraded.
The contractual SLA for "Critical" is indeed still sub-two hours for first contact. The four-hour wait user54 experienced constitutes a breach. However, the larger issue is the triage model. The initial responder now seems to be a pure dispatcher with no technical context, leading to multiple back-and-forth cycles just to restate the problem we already documented. The depth of the eventual engineering engagement is less consistent; we've received canned KB article links for issues that were clearly novel bugs, which never happened three years ago.
This points to a structural scaling problem, not just queue lengths. The support workflow is fragmented, adding latency before any real troubleshooting begins. Have you compared your SLA wording from your initial contract to your current one? I've found subtle changes in the definitions of "response" and "work hours" over renewal periods.
—chris
The shift you're describing, where the initial premium support feels like a concierge service that later normalizes, is the inevitable lifecycle of a scaling SaaS vendor. It's a pattern I've charted in marketing automation platforms as well. The real question isn't if it happens, but when the contractual guarantees get quietly rewritten to match the new, slower reality.
You cut off at "premium p..." which I assume is "premium plan." That's the core of it. Pull out your contract and look at the defined SLA for "critical" severity. I'd bet the definition has been narrowed, or the response clock now starts from some internal triage event rather than ticket creation. That four-hour wait for an acknowledgment is a breach of the old-world SLA, but likely compliant with a revised, more "operationally efficient" one. Have you received any SLA amendment notices? They often bury them in broader "terms updates."
Attribution is a lie, but we need the lie.
That's a really good point about the contract language. I haven't been through a vendor scaling cycle firsthand yet, so hearing you've charted this pattern is eye opening. It makes total sense that the SLA definitions would be the first thing to get quietly adjusted.
> the response clock now starts from some internal triage event rather than ticket creation
This feels like it could be a major part of the issue user717 is hinting at. If the SLA timer only starts after some internal handoff, then a four hour wait in the "dispatch" queue looks fine on paper, even if it feels like a breach to the customer staring at a frozen server. It's a clever, if frustrating, way to technically meet a guarantee while the actual experience degrades.
Has anyone actually received one of those SLA amendment notices from SentinelOne? I'm curious if they frame it as an "improvement" or just bury it in a quarterly terms update like you said.