Copy page

Internal Operations

Health Probe Telemetry Filtering

Health Probe Telemetry Filtering

Successful platform probe traffic is filtered out of shared backend traces and logs to reduce observability spend without hiding real failures.

Filtered probe endpoints

Only these exact probe paths are suppressible:

• /health
• /alive
• /api/health

Normalization rules:

• Query strings are ignored for matching.
• A trailing slash is treated as the same route.
• Matching is exact after normalization.

Examples that are filtered when they return 2xx or 3xx:

• /health
• /health/
• /health?check=readiness
• /alive
• /api/health

Examples that are not filtered:

• /healthz
• /healthy
• /api/v1/auth/webhooks/health
• /api/v1/smsc/health
• Any probe route returning 4xx or 5xx
• Any probe route where no response status code is available

Suppression rules

Telemetry is suppressed only when both conditions are true:

1. The normalized request path matches one of the exact probe paths above.
2. The response status code is explicitly in the 200-399 range.

This means:

• Healthy readiness/liveness noise is dropped.
• Unhealthy probes such as 503 Service Unavailable are still visible.
• Domain health endpoints used by operators or integrations remain visible.

Backend implementation points

Shared filtering is applied in two places:

• Tracing: HealthCallFilterProcessor suppresses only successful server spans for probe endpoints.
• Logging: shared Serilog setup excludes only successful probe request logs when path and status code properties are present.

Frontend / portal behavior

Portal server entries keep /api/health as the first request-handling branch so probes return before React Start or proxy handling. We intentionally do not add broad browser-side ignoreUrls filtering for /api/health, because that would also hide failed health calls.

Verification queries

Use these checks after deployment.

Trace queries

Look for successful probes — the expected result is no data:

Code
url.path in ["/health", "/alive", "/api/health"]
AND http.response.status_code >= 200
AND http.response.status_code < 400

Or, for older semantic convention tags:

Code
(url.path = "/health" OR url.path = "/alive" OR http.target = "/api/health")
AND http.status_code >= 200
AND http.status_code < 400

Look for failed probes — the expected result is data is still present:

Code
url.path in ["/health", "/alive", "/api/health"]
AND http.response.status_code >= 400

Log queries

Look for successful probe request logs — the expected result is no data:

Code
(RequestPath = "/health" OR RequestPath = "/alive" OR RequestPath = "/api/health")
AND StatusCode >= 200
AND StatusCode < 400

Look for failed probes — the expected result is data is still present:

Code
(RequestPath = "/health" OR RequestPath = "/alive" OR RequestPath = "/api/health")
AND StatusCode >= 400

Look for domain health endpoints — the expected result is data is still present when called:

Code
RequestPath = "/api/v1/smsc/health"

Adjust field names to your backend if your log or trace store exposes equivalent properties such as Path, http.target, or http.status_code.