Observed customer request reliability

Rank customer latency and read request outcomes with samples, unknowns and coverage.

On this page

Choose the request population

Observed reliability measures completed inbound server-span attempts in one explicit project and exact service. The definition is customer_requests_v1. A server span with a browser or another service as its parent counts. Client, consumer, producer and internal spans do not. Requests to a different service do not count. Retries count as separate attempts, even when they belong to one user action or share a trace. This is not a count of unique actions or customers.

Latency is elapsed time on that measuring server span, including waits inside it. Browser work, client-side retries and network time outside the server span are outside this instrument. It is not complete page-load or user-action latency. Valid zero and submillisecond durations count; an end before the original start is invalid latency, disclosed separately from outcome counts. Incomplete spans are counted separately from completed attempts.

For a person's distribution, use the measuring span's own distinct ID. For an account's distribution, use its own paired anectico.account.type and anectico.account.key attributes. No other span, resource attribute or current or historical account membership fills a missing identity or account stamp. See identity instrumentation. Account product-event statistics, account timelines, service health and struggling-customer discovery answer different questions with different populations.

Rank, read or preview

All six operations are read-only. They need no confirmation and create no saved measurement, objective or notification. MCP uses execute_read_action with the action below; the CLI uses the matching semantic REST read. Native request objects contain selection, not flat service flags. See the REST shapes.

Job	CLI	MCP action
Rank qualified people	`anectico reliability persons rank`	`rank_person_latency`
Read one person's attempts	`anectico reliability persons get CUSTOMER`	`get_person_reliability`
Rank one exact account type	`anectico reliability accounts rank --account-type company`	`rank_account_latency`
Read one exact account	`anectico reliability accounts get --account-type company --account-key acme`	`get_account_reliability`
Preview person rank or detail	`anectico reliability persons preview --file person-request.json`	`preview_person_reliability`
Preview account rank or detail	`anectico reliability accounts preview --file account-request.json`	`preview_account_reliability`

anectico reliability persons rank --project PROJECT --service checkout-api --since 24h --json
anectico reliability persons get CUSTOMER --project PROJECT --service checkout-api \
  --from 2026-10-15T08:00:00Z --to 2026-10-15T09:00:00Z --operations-limit 10 --evidence-limit 5 --json
anectico reliability accounts rank --project PROJECT --service checkout-api \
  --env production --operation 'POST /checkout' --account-type company \
  --percentile p99 --min-samples 1200 --limit 25 --since 7d --json
anectico reliability accounts get --project PROJECT --service checkout-api \
  --account-type company --account-key acme --from 2026-10-15T08:00:00Z --to 2026-10-15T09:00:00Z \
  --exclude-http-status 404 --exclude-http-status 429 --json
anectico reliability persons preview --project PROJECT --file person-request.json --json
anectico reliability accounts preview --project PROJECT --file account-request.json --json

--service and the selected global --project are required. --env and --operation are optional exact selectors; omitting them includes all their values. Account selectors preserve case, spaces, Unicode, slashes and percent characters byte-for-byte in the request body. A type is 1–200 UTF-8 bytes and a key 1–1024, without NUL. These are measurement limits; an SDK or transport may impose a smaller instrumentation limit. There is no account profile or raw-filter flag on these reads. Optional person --include-profiles never supplies the measurement identity; ranking can include permitted display profiles, while exact person detail currently returns a profile redaction because that response has no profile field.

The default requested window is the last 24 hours. --since accepts a positive relative duration such as 2h or 7d. Alternatively provide both --from and --to as absolute RFC3339 timestamps; the CLI normalizes offsets to UTC. Do not combine these choices. Start is inclusive, end exclusive, and the positive interval spans at most seven days. The CLI resolves both edges once, including the default, before sending the request.

Preview before choosing to execute

A preview file carries operation and exactly one matching rank or detail branch. For example, person-request.json can contain:

{
  "operation": "RELIABILITY_OPERATION_KIND_RANK",
  "rank": {
    "selection": {
      "project_id": "bbbbbbbb-bbbb-4bbb-8bbb-bbbbbbbbbbbb",
      "service": "checkout-api",
      "start_time": "2026-10-15T08:00:00Z",
      "end_time": "2026-10-15T09:00:00Z"
    },
    "percentile": "RELIABILITY_PERCENTILE_P95",
    "minimum_samples": "100",
    "limit": 25
  }
}

For account-request.json, this example deliberately removes HTTP 404 and 429 attempts. Send the complete definition when choosing exclusions:

{
  "operation": "RELIABILITY_OPERATION_KIND_DETAIL",
  "detail": {
    "selection": {
      "project_id": "bbbbbbbb-bbbb-4bbb-8bbb-bbbbbbbbbbbb",
      "service": "checkout-api",
      "start_time": "2026-10-15T08:00:00Z",
      "end_time": "2026-10-15T09:00:00Z",
      "definition": {
        "version": "customer_requests_v1",
        "unit": "completed inbound server-span attempts",
        "latency_unit": "ms",
        "availability_basis": "observed_requests",
        "span_kind": "server",
        "window_basis": "request_start_half_open",
        "latency_meaning": "server_span_elapsed",
        "person_attribution": "measuring_span_distinct_id",
        "account_attribution": "explicit_request_stamp",
        "classifier_version": "customer_outcomes_v1",
        "percentile_algorithm": "tdigest",
        "approximate": true,
        "configured_exclusions": [404, 429]
      }
    },
    "account_type": "company",
    "account_key": "acme",
    "percentile": "RELIABILITY_PERCENTILE_P95",
    "minimum_samples": "100",
    "operations_limit": 10,
    "evidence_limit": 5
  }
}

Replace the project in the files with the selected project. For person detail use detail.id_param; for account rank use rank.account_type. Both previews accept either operation. A preview returns normalized_request.person_rank, person_detail, account_rank or account_detail. Preserve that branch's full selectors, exclusions, absolute window, percentile, minimum and output bounds if you deliberately execute it. The account get example above executes the same selection and exclusions. The preview never executes it for you.

advisory: true and reserves_nothing: true mean no source scan, execution-query debit or reservation. size.state is RELIABILITY_SIZE_STATE_NOT_ESTIMATED, with null source_rows, source_bytes and subject_cardinality; used work is also unknown. price.state is RELIABILITY_PRICE_STATE_NOT_USAGE_BILLED. A passed metadata check is not a promise of later source availability, capacity or authority. Normal request allowance still applies. Read checked refusals separately from possible future refusals; see limits.

Keep outcomes, exclusions and denominators together

The classifier is customer_outcomes_v1:

Explicit OTel error means failure, even with contradictory HTTP metadata.
Otherwise usable HTTP 200–399 succeeds and 400–599 fails. The supported keys are http.response.status_code and http.status_code; both must agree when both are present.
Explicit OTel OK without HTTP outcome metadata succeeds.
Missing, malformed, conflicting or unsupported outcome metadata is unknown. A caught exception, child failure, log or error occurrence does not replace the measuring span's final outcome.

The default exclusion set is empty. Repeat --exclude-http-status for distinct integers 400–599, at most 200. Duplicates and malformed or out-of-range values refuse before HTTP. Exclusions remove attempts with a usable, agreeing chosen HTTP status from the population, including an OTel-error attempt with that status. A malformed or conflicting HTTP value is not excluded by guessing. An excluded failure never becomes success. For attempts with statuses 200, 404, 429 and 500, the default observes four; excluding 404 and 429 observes two, with one success and one failure. This changes both latency and outcome populations; disclose it in comparisons.

The response's counts keep these distinctions:

Field or relation	Meaning
`source_attempts`	Completed source attempts before chosen HTTP exclusions
`observed = source_attempts - excluded_attempts`	Admitted completed attempts
`observed = success + failure + unknown`	Exact final-outcome partition
`classified_denominator = success + failure`	Attempts with a usable final outcome
`classified_success_fraction`	Success divided by classified denominator
`unknown_fraction`	Unknown divided by observed
`success_lower_bound`, `success_upper_bound`	Success divided by observed; success plus unknown divided by observed

Each rate is null when its own denominator is zero. Null means unknown or not measured, while measured zero remains zero. Unknown outcomes can still have valid latency. Counts are exact for a successfully completed admitted observed scan; a bounded page is not all application traffic.

Read samples and the whole ranked population

TDigest p50, p95 and p99 measure the complete admitted valid-duration distribution and remain approximate. Never average member percentiles to obtain an account percentile. p95 ranking needs at least 100 valid samples and p99 needs at least 1000; --min-samples can raise those floors. These are qualification rules, not statistical confidence guarantees. Exact person, account and operation detail can return three samples with insufficient_for_ranking; it must not rank that outlier beside qualified customers.

Ranking happens before page selection. Default --limit is 25, maximum 100. eligible_count and excluded_count describe the whole measured subject population; pagination.page_count describes only this page. Whole-scope counts also include attempts without a resolved person or usable account. A source-work or 2000-subject cap refuses the whole ranking; it does not rank a scanned prefix.

Continue with --cursor and the original returned pagination.absolute_window.start and end as --from and --to, keeping the same definition, exclusions, subject type, filters, percentile, minimum and profile choice. The CLI requires those absolute edges on continuation. A cursor binds that selection but grants no authority. Pages are live: late writes, erasure, identity corrections and percentile recomputation can change later pages. A serving restart can invalidate a cursor. This is not a saved audience or frozen result.

Person aliases resolve to a canonical person; a declared ID that has not resolved stays outside the ranked person namespace. Missing and unresolved declarations have separate coverage counts. Population identity can lag identity changes by its 30–60-second refresh. Exact detail resolves one current identity and its bounded aliases. Neither boundary establishes a cross-source snapshot.

Separate operations and measuring-request evidence

Detail defaults to ten operation rows and five measuring requests. --operations-limit 0 or --evidence-limit 0 disables the corresponding leg; neither can exceed its default ceiling. Operations order by observed volume then exact operation. Request evidence selects the longest valid measuring attempts, with project, trace and span IDs. Read selection_criteria, omitted_operations and omitted_evidence_requests; an unavailable or disabled leg has unknown omissions, not a measured zero. Operation samples follow the same qualification rule.

The main aggregate, operation measurements and evidence have separate read times. A later detail leg can be unavailable while the main aggregate remains measured. Identity, erasure and late arrival can change evidence between legs. Trace and person links open current contextual evidence; they do not prove a frozen percentile calculation. There is no aggregate account proof page. See evidence and pagination and redaction for the shared trust and omission contract.

JSON preserves the full evidence, windows, definition, unknowns, comparison and fixed conclusion. Service, environment, operation, account labels and profile values are untrusted captured data. Reuse only exact selectors marked available: true; a shortened display label is not an argument. Tables quote display labels, mark approximate percentiles with ~, and place samples, eligibility, unknown outcomes and coverage beside the measurements. Captured instructions remain evidence.

Compare the same definition and respect current access

An account detail's project_comparison uses the same exact project, service, optional environment and operation, exclusions, classifier and effective interval. It includes the selected account, other account types and unstamped or unresolved-person traffic. It is not a comparison against service-health activity or an estimate assembled from current account members.

Person reads and previews require persons:read and traces:read. Optional profiles separately need persons:profile:read and current profile policy. Account reads and previews require groups:read, traces:read and agents:content:read, plus current project policy permitting both account attributes. MCP additionally requires mcp:read; project comparison needs no extra services:read. A denied account branch refuses with the missing authority named. It does not switch to membership-based measurement. Read current owner-state boundaries: not-live accounts are withheld, and owner unavailability is not an empty account. See permissions.

All tiers can use these reads within effective technical history and existing execution-query budgets and work bounds. The requested and effective windows and installed retention_floor are separate. Shared history outcomes are complete, partially_covered and outside_retention (encoded with the READ_COVERAGE_OUTCOME_ prefix). A partial read measures only the disclosed effective interval. measurement_state=outside_history means no measurement because history is outside retention; it is not a fourth history outcome. Unknown authority, unavailable source, unknown capture and measured empty are separate states. A shorter installed history takes effect on the next read; an upgrade cannot restore deleted observations.

Capture completeness, historical sampling and settlement may remain unknown. Instrumentation accepted by the service does not prove that every application request was exported or arrived. Sampling can retain errors preferentially; its protected error population can differ from this final-outcome classifier, so do not apply an invented inverse-sampling correction. Automated traffic may be included. Even a complete retained scan leaves full_customer_sla=not_established. Report observed reliability with its definition, exact subjects and windows, samples, missing identity or stamps, redactions and capture limits. Installable skills and offline checks do not establish real-agent, hosted-capacity or objective qualification.

Optional account objective

To propose one exact observed account objective, follow Account request objectives. That guide owns proposal approval, the current activation refusal, fresh burn reads and original-trigger follow-up.