Having recently completed a detailed evaluation of OpenPipe for potential integration into our observability stack, I must concur with the sentiment expressed in this thread's title, albeit reluctantly. My team's experience with their customer support during a critical proof-of-concept phase was significantly below the standard we expect from vendors in the observability and data pipeline space. This is particularly concerning given that OpenPipe positions itself as a solution for production-grade data collection and transformation.
The primary issue we encountered was not the competence of the support engineers when they *did* respond, but the inconsistent and lengthy latency in their initial replies. During our evaluation, we faced a configuration issue where our high-cardinality Prometheus metrics were being sampled incorrectly after passing through the OpenPipe aggregation layer. The symptom was a persistent discrepancy between the raw data in our self-managed Prometheus and the aggregated data surfaced in our downstream Grafana dashboards when routed through OpenPipe.
We opened a detailed ticket, including:
* Our OpenPipe pipeline configuration (YAML)
* A sample of the discrepant time-series data (exported as JSON)
* Our Prometheus scrape configuration snippet
* Screenshots of the Grafana panels showing the delta
The initial response took **47 hours**. For a platform handling observability data, such a delay in addressing a data fidelity issue during a POC is a severe red flag. It suggests either under-resourcing of support or a lack of priority for technical pre-sales engagement. Subsequent interactions, while technically accurate, were slow, often with 12-24 hour gaps between each message. This turn-around time is incompatible with the operational tempo of an SRE or platform engineering team dealing with live metrics and potential incidents.
To provide a concrete example, here is a sanitized version of the configuration in question where we suspected the aggregation logic:
```yaml
pipeline:
- name: prometheus_aggregation
action: aggregate
parameters:
match:
- '{__name__=~"container_cpu_usage_seconds_total.*"}'
interval: 2m
operation: sum
group_by: ["cluster", "namespace", "pod"]
output:
format: prometheus_remote_write
```
The support engineer correctly identified that our `group_by` clause was inadvertently causing a grouping key collision with a pre-existing label from our Kubernetes service discovery, leading to aggregated series with overlapping dimensions. The solution was straightforward, but the time-to-resolution was protracted purely by the communication latency.
This experience forces a broader cost-benefit analysis. When evaluating a tool for critical infrastructure, support responsiveness is a non-functional requirement as critical as uptime. A slow response to a configuration issue during peacetime implies potentially catastrophic delays during a production outage. For organizations operating under strict SLOs, this must be factored into the total cost of ownership, potentially offsetting any per-unit-cost savings the tool itself might offer. I am curious if others have conducted similar analyses or if our experience was an outlier.