zeroclaw-labs/zeroclaw · warning

Nevis health check failed: HTTP {}

Error message

Nevis health check failed: HTTP {}

What it means

health_check GETs {instance_url}/auth/realms/{realm} (nevis.rs:321-337) and fails on any non-2xx status. A separate earlier message ('cannot reach instance') covers connection failures. This method exists for startup and readiness diagnostics, not per-request auth.

Source

Thrown at crates/zeroclaw-runtime/src/security/nevis.rs:336

    }

    /// Health check against the Nevis instance.
    pub async fn health_check(&self) -> Result<()> {
        let health_url = format!(
            "{}/auth/realms/{}",
            self.instance_url.trim_end_matches('/'),
            self.realm,
        );

        let resp = self
            .http_client
            .get(&health_url)
            .send()
            .await
            .context("Nevis health check failed: cannot reach instance")?;

        if !resp.status().is_success() {
            bail!("Nevis health check failed: HTTP {}", resp.status().as_u16());
        }

        Ok(())
    }

    /// Getter for instance URL (for diagnostics).
    pub fn instance_url(&self) -> &str {
        &self.instance_url
    }

    /// Getter for realm.
    pub fn realm(&self) -> &str {
        &self.realm
    }
}

// ── Wire types for Nevis API responses ─────────────────────────────

View on GitHub (pinned to 88bb9c8533)

Solutions

1. From the ZeroClaw host, curl {instance_url}/auth/realms/{realm} and confirm it returns 200
2. Fix instance_url or realm if the realm root returns 404
3. For 5xx or unreachable instances, mark the gateway degraded and retry — do not crash the process

Treat any health_check error as 'not ready': report unhealthy to the orchestrator and let the probe schedule retry; distinguish 'cannot reach instance' (network/DNS) from 'HTTP {code}' (config or IdP state) in logs.

When it happens

Trigger: Calling health_check when the realm is misspelled (404), Nevis sits behind a proxy returning 502/503, or instance_url points at the wrong host or path prefix.

Common situations: Readiness probe wired to health_check during an IdP upgrade window; DNS not resolvable from the ZeroClaw host; instance_url with an extra path segment producing 404.

Related errors

• Nevis introspection returned HTTP {}
• Nevis session validation returned HTTP {}
• Google device code request failed ({}): {}
• Token is not active (revoked or expired)
• GET /channels/{id} returned {}: explicit channel_id is not a

AI-assisted analysis of zeroclaw-labs/zeroclaw@88bb9c8533 (2026-08-23). Data as JSON: /api/errors/97d1bacf7e434502. Report an issue: GitHub.