Hi Community,
I am writing this post to bring attention to a conceptual bug in the Overview of the Google Apigee Proxy
regarding how HTTP response codes are evaluated, as standard support channels have unfortunately dismissed the issue.
I previously raised this through support chat, but the answer I received was that "this is how it was designed and it cannot be changed." Since this fundamentally breaks standard HTTP logic, I am bringing it to the community to raise awareness and get traction from the product team.
Currently, the extension is classifying HTTP 201 (Created) responses as errors, directly impacting the Failure Rate metric.
The Issue
As per the RFC 7231 HTTP standard, any 2xx series code indicates a successful request. Specifically, a 201 Created status means the request has been fulfilled and has resulted in one or more new resources being created. It is not a failure.
As you can see in the screenshot below, during a period where all actual error codes (500, 502, 504, 400, etc.) are at 0%, the Failure rate chart matches the exact percentage of the 201 responses (2.64%).
/ui/apps/dynatrace.classic.gcp/ui/entity/
Overview of the Google Apigee Proxy
Impact
Skewed Metrics: This behavior artificially inflates the failure rate of Apigee services.
False Alarms & Alert Fatigue: It triggers unnecessary alerts for successful transactions, impacting operations.
Impacted SLAs: It distorts the availability reports delivered to business stakeholders.
Since this is hardcoded or misconfigured by default within the extension's internal logic—and cannot be overridden via standard service error detection settings—this requires a fix from the extension maintainers. Accepting "it's by design" for a metric that treats success as a failure is not a viable option for an enterprise observability platform.
Thanks in advance for your insights!
Featured Posts
