Can successful reads hide failed pull-request writes in availability metrics?

Yes. Successful reads can dominate a request-weighted availability metric even when every observed attempt at a particular pull-request write operation fails. The aggregate can be mathematically correct while answering the wrong operational question: how many requests succeeded, rather than whether developers could complete a critical action.

GitHub explicitly identifies this risk in its August 2026 availability report, published September 9, 2026. GitHub says its pull-request monitoring now measures merge, review, and comment failures independently because high read volume could otherwise mask a failing write path.

Why a high success rate can conceal a broken operation

For a request-based indicator, aggregate success is:

Aggregate success = successful eligible requests / total eligible requests

When eligible requests are grouped by operation, the aggregate is a traffic-weighted average of those operations’ success rates. An operation’s influence depends on its request volume—not on how important it is to the user.

Consider this illustrative window, which is not reported GitHub traffic:

Operation	Eligible attempts	Successful attempts	Success rate
Reads	999,000	999,000	100%
One write operation	1,000	0	0%
All requests	1,000,000	999,000	99.9%

The aggregate reports 99.9% success while every eligible attempt at the write operation fails. Whether that aggregate triggers an alert depends on the alert’s rules and evaluation window; the percentage alone does not establish that each operation is healthy.

The weighting also makes the metric sensitive to traffic mix. With the same 1,000 failed writes, adding more successful reads raises aggregate success without repairing a single write. Conversely, fewer successful reads would lower the aggregate even if write behavior stayed unchanged.

What GitHub’s monitoring update establishes

GitHub’s reported change is specifically about observing merge, review, and comment failures independently. That granularity matters: even a combined “writes” metric can dilute a lower-volume operation’s failures behind successful traffic from another write operation.

The monitoring statement describes a potential blind spot and a monitoring improvement. Its wording that reads “could” mask failures does not, by itself, establish that a particular outage went undetected or that a known number of failed writes disappeared from previous reporting.

The transferable lesson is narrower and more useful: critical operations should remain observable regardless of how much unrelated successful traffic the system serves.

Give each critical write its own denominator

A practical design derived from this risk is to maintain separate success indicators for merging, submitting reviews, and posting comments:

Merge success = successful eligible merge attempts / eligible merge attempts
Review success = successful eligible review attempts / eligible review attempts
Comment success = successful eligible comment attempts / eligible comment attempts

These are suggested indicator definitions, not a description of GitHub’s internal implementation.

For each indicator, document three things:

• Eligibility: Which attempts belong in the denominator? Make the treatment of invalid requests and expected policy rejections explicit.
• Success: What outcome counts as completing the operation? Define the intended result rather than leaving “success” implicit.
• Counting unit: Does the indicator count individual requests or logical user actions? Specify how retries are counted so numerator and denominator describe the same unit.

The success definition deserves particular care. Google’s Monitoring Distributed Systems notes that errors can be explicit, such as HTTP 500 responses, or implicit, such as an HTTP 200 response containing the wrong content. Applied here, define success around the intended write outcome, not merely a nominally successful response code.

Display attempt and failure counts alongside percentages. A zero-attempt window has no observed success rate; display it as such rather than treating it as 100% successful.

Make alerts independent of read volume

Keep aggregate availability as a summary, but do not make it the sole alerting input for pull-request health. Evaluate each critical write operation against its own reliability objective, using its own eligible traffic.

A useful validation exercise is to model complete merge failure while reads remain successful. Hold merge attempts, outcomes, alert settings, and the evaluation window constant, then increase only successful read volume. If that change clears the merge alert, its calculation still contains the dilution problem.

For the dashboard, show write traffic, failures, and latency, with relevant saturation signals available for investigation. Treat these as complementary views rather than reasons to page on every fluctuation. Google’s monitoring guidance recommends simple, predictable, reliable incident-detection rules and symptom-focused paging, while reserving cause-oriented information primarily for debugging.

Keep the summary, preserve the distinction

Aggregate request success answers a legitimate question about the total population of requests. It does not guarantee that every operation is healthy.

For pull requests, the decisive dashboard question is therefore not just “Are requests succeeding?” It is also “Can developers merge, review, and comment?” Separate indicators preserve those answers even when successful reads vastly outnumber failed writes.