Why fallback results never close an alert

Providers fail. Free tiers hit quotas, keys expire and networks drop. ThirdEYE is built so that analysis degrades instead of stopping.

The fallback chain

Providers are tried in a configured order (for example Groq, Gemini, Mistral, OpenAI, then a local Ollama model). The chain ends in built-in rule-based logic, so an alert is always triaged even with no key configured. Circuit breakers and cooldowns stop a failing provider from slowing every alert.

The guardrails

  • A result produced by the rule-based fallback is marked as such.
  • A fallback result never closes an alert automatically.
  • A fallback-origin verdict is never reused for later alerts.
  • High and critical alerts are never auto-closed in any case.

Strict mode

For providers you add in the setup screen, an administrator can switch fallback off. Analysis then uses only the chosen provider and the built-in logic, which is useful when you want one paid provider to be the only external service that sees alert data.

The point is not to make a degraded answer look good. It is to make sure a degraded answer cannot quietly make a final decision.

See it on your own alerts.

Book a walkthrough with the team. We will show the platform end to end, tell you what is production-ready and what is not, and discuss how it would sit next to your existing SIEM.