Property Access Reviews: Readiness Health Endpoint Checks for Cached API Credentials

Use a cached credential-and-tier observation for readiness, and give that observation an explicit age limit. If the last confirmed observation is still fresh, return ready without contacting the account API. If it is stale and the refresh is refused, return degraded, preserve the last-known evidence for diagnosis, and let a separate policy decide whether the node should receive traffic.

That separation is the decision. A property-management access review needs evidence that a service account can still perform the work assigned to it; a process ping proves only that the process answers. Calling the upstream account API on every probe creates another problem: probe volume becomes authentication traffic, and an upstream refusal can evict every otherwise useful node at once. The spend ceiling and the tolerance for refused traffic therefore belong in the same architecture record.

Decision rule: cache the observation, bound its age, and never describe stale evidence as current.

How should readiness health endpoint checks validate an API credential?

The readiness contract has four invariants. First, the response distinguishes process availability from credential evidence. Second, a successful observation records only the minimum fields needed for the review: a pseudonymous credential key, allowed capability set, tier class, observation time, and result. Third, a failed refresh does not overwrite the last successful observation. Fourth, neither the endpoint nor its telemetry emits the credential secret.

Evidence expires.

OWASP recommends limiting who can access secrets, applying least privilege, rotating secrets, and auditing secret use. Those controls shape the boundary here. The cache stores an assessment of a credential, not the credential value. The Node.js process reads the secret through its normal secret-delivery path, uses it for the upstream check, and discards request-local material. The review record can then answer “which capability was confirmed, when, and under which policy?” without turning logs into a second secret store.

Freshness is local policy, not a universal constant. For an illustrative portfolio, suppose 24 application nodes are probed every 10 seconds. A direct check would request 144 upstream validations per minute: 24 x 6. A 60-second shared observation reduces the intended refresh demand to roughly one validation per minute per credential, provided refreshes are coalesced. Those are design inputs, not benchmark results. Change the node count, interval, cache scope, or credential partition and the arithmetic changes.

The failure boundaries are deliberately unequal. An invalid credential is authoritative evidence and should become not_ready. A refused or timed-out refresh is an observation failure and should become degraded while the previous evidence remains within its maximum stale window. After that window, the system no longer has defensible evidence; it becomes not_ready. Fast failure matters.

Refusal is ambiguous.

Record the state machine before choosing status codes

Three states are enough for the endpoint, but they must not be collapsed into one Boolean.

The distinction between degraded and not_ready protects two different budgets. Treating every refusal as fatal protects certainty but can remove all nodes during a shared dependency event. Treating all cached success as ready protects availability but can keep an access path alive after its evidence has expired. The stale window is the explicit compromise.

For example, choose a 60-second fresh window and a 5-minute maximum stale window only after the access-review owner accepts that exposure. The first value caps routine validation traffic. The second caps how long a node may continue under unrefreshed evidence. Neither number should be copied blindly. A leasing workflow that changes privileges rarely and a staff offboarding workflow that demands prompt revocation do not carry the same risk.

Put the critical path behind one observable request

The public probe should be cheap and deterministic. A scheduler or single-flight refresh path owns upstream validation; the request handler reads the resulting snapshot. This prevents concurrent probes from multiplying calls when the cache expires.

The following curl request exercises the critical path without printing a secret. The response fields are an example contract for a Node.js service, not a claim about a particular framework:

curl --silent --show-error \
  --header 'Accept: application/json' \
  http://127.0.0.1:3000/ready

{
  "status": "degraded",
  "credentialRef": "property-ops-review",
  "requiredCapability": "access-review:read",
  "tierClass": "managed",
  "observedAt": "2026-10-15T02:00:00Z",
  "ageSeconds": 83,
  "refresh": "refused"
}

The handler should return a success-class HTTP response for ready, a distinct documented response for degraded, and a failure-class response for not_ready; the exact mapping belongs to the traffic controller's contract. Do not assume an orchestrator understands a custom body. If its probe reacts only to the HTTP status, map statuses deliberately and test the mapping during deployment.

The refresh worker needs a single-flight guard, a short request deadline, and bounded retry with jitter. More retries are not free. They increase upstream work precisely when refusal is already the signal. Keep the previous successful snapshot immutable, publish the new snapshot only after the credential and required tier are both confirmed, and classify rejection separately from transport failure.

This design has limitations. A local per-process cache gives each node a slightly different view and repeats refresh work across the fleet; a shared cache reduces that duplication but adds another dependency and requires provenance controls. The state model also cannot prove that every downstream property system will accept the credential. It proves only the capability and tier tested at the account boundary. Choose direct, uncached validation when each admission decision must reflect the upstream's current answer and the upstream has explicitly budgeted capacity for that probe load. Choose background reconciliation when a signed access review needs broader evidence than readiness can responsibly collect.

Deployment needs one additional check: start with unknown, not optimistic readiness. A new node has no inherited proof unless the cache is intentionally shared and its provenance is verified. During rollout, exercise four cases: confirmed access, explicit credential rejection, tier mismatch, and upstream refusal after a prior success. The last case is where accidental cache replacement usually destroys the evidence needed by the reviewer.

How much telemetry can this decision afford?

Count events before adding labels. With 24 nodes and a 10-second probe, logging every request produces 207,360 events per day: 24 x 6 x 60 x 24. At an illustrative 350 bytes per structured event before indexing overhead, that is about 72.6 MB per day for one low-information endpoint. The calculation is useful even though actual encoded and indexed size depends on the telemetry pipeline.

Do not log every healthy probe. Emit a metric for state, a counter for refresh outcomes, and a structured event on transitions such as ready to degraded. A periodic summary can preserve denominator data without preserving six near-identical lines per minute per node. Sample healthy request traces aggressively; retain refusal and rejection transitions because they explain why traffic policy changed.

Keep less, on purpose.

Cardinality deserves the same restraint. status, refresh_outcome, and a small tier class are bounded labels. Credential values, property IDs, tenant IDs, request IDs, and error strings are not. Keep those out of metric labels. A pseudonymous credential reference may belong in a restricted review event, but even there its retention should match the review period rather than the longest available storage setting.

Retention math makes the trade visible. If transition events average 700 bytes and a credential changes state 20 times per day across 100 credentials, the raw event body is about 1.4 MB per day before replication and indexes. If instead every node logs every probe at 350 bytes, the earlier per-service estimate applies regardless of whether anything changed. The smaller stream is also the better audit narrative: it records decisions, not heartbeat noise.

Why reject a live validation on every probe?

Live validation appears simpler because it removes cache policy. It also couples node admission to the latency, availability, and refusal policy of the account service. In a multi-node property platform, synchronized probes can amplify that dependency, and the resulting logs measure probe cadence more than access risk. This option was rejected for routine readiness because it spends upstream capacity without producing proportionally better review evidence.

It still has a valid use case. Run an uncached validation as a controlled pre-deployment check, an operator-triggered diagnostic, or a low-frequency background reconciliation. Those paths can tolerate a stricter deadline, richer audit context, and explicit refusal handling without making each load-balancer decision wait on a remote account system.

The accepted design is less absolute. Fresh cached evidence admits traffic, a temporary observation failure is visible as degraded, and expired or negative evidence refuses traffic. The access reviewer receives a compact sequence of capability decisions with honest timestamps. Operations receives bounded upstream demand. Observability retains the transitions that matter instead of charging for a continuous transcript of healthy probes.

References

• https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html