BerriAI/litellm · error · HTTPException
Akto guardrail service unreachable
Error message
Akto guardrail service unreachable
What it means
Akto's API could not be reached during a guardrail evaluation; behavior follows unreachable_fallback — fail_open lets the request through with a critical log, fail_closed blocks it. This message accompanies the fail_closed branch.
Source
Thrown at litellm/proxy/guardrails/guardrail_hooks/akto/akto.py:350
str(guardrails_result.get("Reason", "")),
)
def handle_unreachable(
self,
inputs: GenericGuardrailAPIInputs,
error: Exception,
) -> GenericGuardrailAPIInputs:
"""Handle Akto being unreachable based on fail_open/fail_closed config."""
if self.unreachable_fallback == "fail_open":
verbose_proxy_logger.critical(
"Akto unreachable (fail-open): %s",
str(error),
exc_info=error,
)
return inputs
verbose_proxy_logger.error("Akto unreachable (fail-closed): %s", str(error))
raise HTTPException(
status_code=503,
detail="Akto guardrail service unreachable",
)
async def fire_and_forget_request(
self,
*,
guardrails: bool,
ingest_data: bool,
payload: dict,
) -> None:
"""Send a request without awaiting it in the caller. Errors are logged, not raised."""
try:
response: Final = await self.send_request(
guardrails=guardrails,
ingest_data=ingest_data,
payload=payload,
)View on GitHub (pinned to 77b7c6c40c)
Solutions
- Verify the Akto service URL is correct and reachable from the proxy.
- Check network/firewall rules between the proxy and the Akto service.
Example fix
curl -v $AKTO_GUARDRAIL_API_BASE to test connectivity.
Defensive patterns
Strategy: fallback
When it happens
Trigger: Thrown at litellm/proxy/guardrails/guardrail_hooks/akto/akto.py:350 when the library encounters an invalid state.
Common situations: Network failure when calling the Akto guardrail service.
AI-assisted analysis of BerriAI/litellm@77b7c6c40c (2026-08-18).
Data as JSON: /api/errors/170a09dd377c8680.
Report an issue: GitHub.