This anomaly rule detects repeated Ollama server application errors as a potential availability issue. It filters log lines with level ERROR or FATAL, extracts the error message and exit_code, and windows-bins events into 5-minute intervals grouped by host. It computes: error_count, first_seen, last_seen, unique_errors, and error_messages, exit_codes. If error_count exceeds thresholds (greater than 5 = critical, greater than 2 = high, otherwise medium), it labels the event as attack_type "Repeated Ollama Application Errors" and outputs a table with first_seen, last_seen, host, error_count, unique_errors, error_messages, severity, and attack_type. The rule acknowledges that Ollama logs do not reliably record process termination, so a crash cannot be confirmed without OS or service-manager telemetry. Guidance emphasizes correlating with service-manager logs to determine if availability was affected, and suggests ingesting Ollama logs via the Splunk TA-ollama or HEC with CIM alignment for standardized detections. Known false positives include recoverable load failures, transient registry or network issues, and other repeated errors that may not indicate an outage. References point to the ta-ollama project for context.