I've been deploying and managing Palo Alto Networks NGFWs across enterprise data pipeline environments for several years, primarily for segmenting analytics clusters and securing API endpoints. While I generally respect the technical capability of the hardware and PAN-OS, I've observed a consistent and frankly frustrating pattern with their technical support (TAC) that seems to have worsened post-2020. My issue pertains specifically to the handling of low-severity, non-production-impacting tickets—anything that isn't a SEV-1 or SEV-2.
The operational latency for initial response and, more critically, substantive engagement on these tickets is remarkably high. We're talking about scenarios like:
* Clarification on a specific, non-default behavior in App-ID for a custom application tied to a data ingestion tool.
* Pre-change validation for a planned policy modification that will affect a non-critical analytics subnet.
* Interpreting nuanced log entries (`show log traffic`) that don't indicate an outage but could point to a misconfiguration.
For these, I've documented wait times of 48 to 72 business hours for a first meaningful reply, not just an automated "we've received your ticket" email. This creates a significant drag on operational velocity, especially when compared to other infrastructure vendors in our stack.
I've attempted to analyze this from a process perspective. Is it a resource allocation issue, where lower-severity tickets are simply deprioritized to a degree that borders on neglect? Or is it a procedural one, perhaps related to the required detail in the initial submission? I follow their recommended template rigorously, including always providing:
* A clear, concise problem statement.
* The exact PAN-OS version (e.g., `10.2.3-h3`).
* Relevant configuration snippets (anonymized).
* Output from `show` commands and tech-support files.
```xml
10.0.50.101
10.0.60.22
9092
```
Despite this completeness, the cycle time for resolution or even a knowledgeable "this is by design" is excessive. This forces us to either re-categorize tickets as higher severity just to get attention—which feels unethical and clogs their true high-priority queue—or to dedicate internal engineering time to reverse-engineer behaviors we're already paying for in support contracts.
I'm interested in a data-driven comparison. Is this a universal experience across the Palo Alto user base, or is it potentially correlated with contract tier (we're on Premium Support), geographic region, or the specific support portal? Have any other organizations developed effective workflows or escalation paths to mitigate this delay without abusing the severity system? A side-by-side analysis of response time metrics would be invaluable for community advocacy.
Data is the source of truth.
Your observation about response times on non-critical tickets matches what I've seen flagged in other threads. The post-2020 timeline is key, it lines up with a period of massive growth and support team restructuring for them.
While it's logical for any vendor to prioritize outages, a 72-hour wait for technical clarification creates its own problems. It forces workarounds based on guesswork or stalls projects entirely, which can lead to more severe issues down the line.
What's your ticket escalation path look like? After the initial delay, do you eventually get a competent engineer who resolves it, or does the quality feel rushed?
—AF