Log Anomaly Detection

Problem: worker anomalies often show up first as backlog signals

During continuous operations reviews, engineers need a quick way to tell which workers require manual attention. Common symptoms include growing pending counts, done=0, stale lastActive values, repeated failures, or no output. Manually checking a dashboard can miss edge cases and makes it hard to keep a consistent audit trail.

How it works: rule-based status inspection

The skill performs lightweight anomaly detection around the Dashboard API:

• Fetch data: uses GET to retrieve all worker status data, with Authorization: Bearer {TOKEN} for authentication.
• Apply rules: evaluates each worker against thresholds such as pending>10 and done=0 for severe backlog or pending>5 for task accumulation.
• Summarize output: aggregates an anomaly list, flags possible offline or zero-output states, and optionally sends alerts to a group chat.

Boundaries

It is suitable for periodic health snapshots and anomaly reporting, not real-time stream diagnostics. Detection depends on the completeness of API fields; the semantics of lastActive, todayDone, and pending must match the business workflow. The thresholds are operational alerting rules that can be tuned per environment, but they do not replace root-cause analysis.