Failed Request Percentage is the share of requests that do not complete successfully over a defined measurement period. It is usually calculated as failed requests divided by total requests, and it helps track service reliability, error rates, and application or API health.
What Failed Request Percentage Tells You
Failed Request Percentage is a reliability signal, not just a vanity metric. It shows how often requests are failing relative to total traffic during a measured window, which makes it useful for spotting service degradation, error bursts, and whether an application, API, or dependency is becoming unstable under real load.
Because the measure is a ratio, it is most useful when read alongside traffic volume and latency. A small percentage at very high request volume can represent a material customer impact, while a higher percentage on low volume may point to a narrow but still important integration or endpoint problem.
How It Is Calculated and Interpreted
The basic calculation is straightforward: failed requests divided by total requests, usually expressed as a percentage. The exact definition of “failed” must be consistent, because teams may count HTTP 5xx responses, timeouts, rejected requests, application exceptions, or failed upstream calls differently. Without a stable definition, trend lines become difficult to compare.
Interpretation also depends on the measurement boundary. A user-facing web page, an internal API, and a backend service can each have different failure modes, so a single percentage can hide where the problem actually sits. The metric becomes more actionable when segmented by endpoint, region, tenant, release version, or dependency.
Why Failed Request Percentage Matters for Service Health
This metric is often one of the fastest ways to see whether a service is still meeting its operational purpose. Rising failure rates can indicate overloaded resources, broken deployments, dependency outages, bad configuration, or code paths that are failing only under certain inputs. It is also a useful early indicator for incident detection before users report widespread disruption.
In API-heavy systems, failed request percentage helps distinguish a healthy service from one that is technically reachable but functionally unreliable. That distinction matters because partial failure can spread across retries, queues, and downstream calls, creating more load and turning a local fault into a broader availability issue.
Common Causes and What the Metric Can Hide
Not every failed request is caused by the application itself. Network interruption, authentication problems, rate limiting, upstream dependency faults, expired certificates, and misrouted traffic can all increase the percentage. The metric therefore needs context from logs, traces, and dependency telemetry to identify the actual failure mechanism.
It can also hide important patterns if it is viewed only as a single aggregate number. A stable overall percentage may still contain one endpoint with severe breakage, a release affecting only one cohort, or a surge of failed requests concentrated in one geography. Good analysis looks for distribution, not just the average.
Risk and Threat Considerations
Failed Request Percentage can signal more than routine reliability drift, because repeated failures may expose weak authentication flows, broken authorization paths, misconfiguration, or overload conditions that attackers can amplify. A rising failure rate may also indicate probing, abuse, or deliberate request flooding that degrades availability while blending into normal error noise.
Failure mechanism: The service fails when requests exceed capacity, depend on unstable downstream systems, or encounter logic and control failures that return errors instead of completing successfully. Attackers can exploit the same weak points through flooding, malformed requests, or repeated abuse of fragile endpoints.
Impact: Persistent failure increases customer-facing downtime, erodes trust in the service, and can mask a broader incident if operators assume the errors are only a transient spike. In some environments, it also creates secondary risk through retries, cascading failures, and delayed detection of malicious activity.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while NIST CSF 2.0 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | DE.CM-01 — Networks and network services are monitored to find potential cybersecurity events | Failed request spikes help reveal service degradation and possible attack activity. |
| RS.AN-01 — Investigations are performed to ensure effective response and support forensics | Rising failure rates need investigation to identify whether the cause is fault or abuse. | |
| Recommendation — Monitor request failure trends to surface anomalies and investigate service-impacting events. Correlate failed requests with logs and traces to determine the underlying cause. | ||
| OWASP API Security Top 10 | API4 — Unrestricted Resource Consumption | Traffic that drives failures can indicate exhaustion or abuse of API capacity. |
| API8 — Security Misconfiguration | Configuration errors often surface first as elevated request failures. | |
| Recommendation — Review rate limits and resource controls when failures climb under load or abuse. Check deployment and environment settings when failure rates rise after change. | ||
Practitioner Guidance
What to watch for: Treat the metric as a trigger for investigation when the failure rate changes sharply, when it rises alongside latency or saturation, or when it is concentrated in one route, client type, or dependency. A flat overall percentage should not be taken as evidence that the service is healthy if the underlying distribution is worsening.
Governance implication: Define the failure denominator and failure classes consistently across teams so the metric is comparable over time and across services. A shared definition makes the measure useful for incident review, release validation, and service ownership decisions rather than just post hoc reporting.
Practitioner takeaway: Use failed request percentage as a leading indicator, but always pair it with error breakdowns, dependency data, and traffic context before deciding whether you have a code defect, capacity issue, configuration fault, or attack-driven degradation.
Related resources from NHI Mgmt Group
- What is the difference between network trust and request-level identity trust?
- When should organisations treat failed logins as a serious security incident?
- Why do access-request workflows matter for NHI governance?
- How should organisations use AI in access request approval without weakening control?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on November 9, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org