DocsReliability & Health
Service reliability

Production reliability and assurance

How Querix keeps tenant search healthy, current, observable, and predictable through dependency or provider failures.

Querix API · v1 contractLast reviewed July 2026

01

Readiness and health contract

Querix exposes two health signals. Public readiness answers whether the shared serving path can accept traffic. Authenticated tenant health reports whether one company's index, source database, embedding runtime, cache, and search configuration are ready.

GET/api/v1/ready

Public readiness

Used by load balancers, uptime checks, and the live status indicator in this documentation.

GET/api/v1/{tenant}/health

Authenticated tenant health

Used by customer backends and operators to inspect one tenant's serving dependencies.

Public readiness response
{
  "status": "ok",
  "tenant_mode": true,
  "configured_companies": 1
}

How this website checks health

The website calls its same-origin /api/ready route. That server route probes the Querix Search API, applies a four-second timeout, removes internal detail, and returns a cache-disabled status payload to the browser.

02

The serving data boundary

Indexes discover and rank candidate IDs. The tenant database remains the canonical source of the public rows returned to users. This means display-only changes are visible immediately while changes that affect retrieval text or filter metadata require an index refresh.

  1. 01

    Authenticated tenant request

  2. 02

    Query routing and ID cache

  3. 03

    Deterministic or hybrid candidate retrieval

  4. 04

    Current-row hydration from tenant database

  5. 05

    Mapped public response

03

Tenant configuration and isolation

Each tenant owns an endpoint slug, API keys, database connection, vector namespace, lexical index, cache namespace, cursor sessions, rate policy, request mapping, response allowlist, and usage accounting. Startup validation must reject any unsafe shared identity or storage path.

  • Use a read-only database user for serving and ingestion.
  • Keep vector, lexical, cache, and cursor namespaces tenant-scoped.
  • Use TLS verification for remote databases and secret-manager injection for credentials.
  • Provision conservative connection pools and per-tenant concurrency limits.

04

Index refresh lifecycle

Ingestion is incremental by content hash: read a bounded source page, prepare retrieval text and metadata, update lexical records, embed only changed items, then update vector records. Reconciliation removes IDs no longer present after a successful full scan.

Incremental

Upsert new or changed records without unnecessary embedding work.

Reconcile

Remove stale index IDs only after a complete source scan succeeds.

Replace source

Rebuild retrieval indexes without mutating the tenant's canonical data.

05

Route-aware assurance

Do not treat a warm result-cache hit as representative production throughput. Test deterministic filters, unique semantic queries, repeated semantic queries, provider fallback paths, mixed filters, compatibility mappings, and planned concurrent load independently.

StatusMeaning and action
ReadinessCritical serving dependencies are available for configured tenants.
Tenant healthIndex, database, cache, and dependencies are ready.
Contract checksAuthentication, request mapping, pagination, and public fields stay compatible.
Relevance evaluationExpected query-routing and ranking regressions are caught before release.

06

Monitoring and incident response

One trace should connect request start, cache lookup, planning, vector and lexical retrieval, fusion, reranker attempts, canonical row mapping, and completion. Store route, provider label, fallback reason, cache state, counts, and timing, while omitting raw query text, private fields, and credentials from normal telemetry.

Operational signals

Monitor tenant database availability, cache connectivity, provider failures, rate limits, token usage, disk/RAM, index revision, and p95 latency split by deterministic, semantic, and cached routes.

07

Service assurance checklist

  • Confirm readiness and tenant health after every deployment.
  • Run a deterministic query, a semantic query, and a repeat-query cache check.
  • Refresh indexes incrementally; reconcile only after a successful full scan.
  • Rotate exposed credentials, verify backups, and test restore procedures.
  • Confirm authentication, public fields, and pagination remain compatible after changes.

Need help with your integration?

Talk to us about your catalog and search contract.

Contact engineering