# Service Availability And Impact

## Question

Did the affected TiDB service stop or materially degrade, what customer impact
occurred, and does the incident require immediate human handling?

## Enter When

Use for active or recent node hangs, sustained scrape loss, connection/request
traffic disappearance, restarts, load-balancer/backend concerns, or material
business QPS/error changes. Add it beside the likely lower-level cause
scenario; impact is not a substitute for cause.

## First Batch

1. On the named instance, compare connections, accepted requests or QPS, and
   process readiness/up/restarts with a useful pre-incident baseline.
2. Align the same interval with component-port/blackbox probes and available
   load-balancer/backend health.
3. Quantify cluster/business QPS, errors, and latency relative to the baseline
   and peers.

## Decision

- Sustained loss of previously present service metrics plus `up=0` is a
  service-layer contradiction when generic probes still succeed. It is not a
  benign collection gap unless independent evidence proves monitoring-only
  failure.
- Non-zero aggregate QPS does not disprove impact; report the relative decline.
- Confirmed service loss or a required drain/restart/failover is at least High,
  requires `human_required`, and remains read-only. Use Critical for broad or
  ongoing outage or data-safety risk.

## Strongest Alternative And Stop

Check monitoring-path-only failure on the same entity. Stop after service
outcomes, business impact, and that alternative are observed or one exact
provider gap is named. Do not let host reachability override TiDB outcomes.