What is anomaly detection?
Anomaly detection is the ability for your app to automatically identify when something unusual is happening — and alert the right people before it becomes a problem. It replaces the manual process of someone eyeballing dashboards or waiting for a customer complaint.
The "anomaly" depends entirely on your business. It might be a transaction that's five times the normal value, a piece of equipment drawing more current than usual, a user account logging in from an unexpected location, or a batch process that normally takes 30 minutes running for three hours. What these have in common is that they deviate from a learned or configured baseline.
At the simpler end, anomaly detection is just threshold-based alerting with some statistical context (alert when value exceeds mean + 3 standard deviations). At the more sophisticated end, it's an ML model that learns seasonal patterns and multiple interacting signals before deciding something is genuinely unusual.
When does your app need it?
- You're processing financial transactions and need to flag potential fraud before it completes
- You manage physical equipment (plant, vehicles, HVAC) and want to predict failure before it causes downtime
- Your app handles unusual spending against budgets and you want to proactively surface overruns
- You're running a SaaS platform and want to detect when a customer's usage pattern suggests they're about to churn or have hit a problem
- Your app processes data feeds (inventory, sales, web traffic) and operations teams need to know immediately when something looks wrong
- You have compliance obligations — financial services, healthcare, or government — that require detection and audit of unusual activity
How much does it cost?
Adding anomaly detection typically adds 11–21 hours of development — roughly $2,000–$5,000 AUD at Australian boutique agency rates.
The simpler end covers threshold-based rules with statistical baselines and email/SMS alerts. The more expensive end involves training ML models on historical data, real-time stream processing, multi-signal correlation, and a user-facing alert management interface with tunable sensitivity.
Alert fatigue is a real risk — if the system cries wolf too often, people start ignoring it. Building in sensible defaults, escalation logic (alert again only after X minutes), and per-user notification preferences adds time but is worth it.
How it's typically built
For most business apps, anomaly detection starts with a statistical baseline: compute rolling averages and standard deviations over a lookback window, then alert when a new value falls outside a configurable threshold. This handles most use cases and requires no ML infrastructure.
For more complex patterns — seasonality, multiple interacting metrics, high-frequency data — cloud services like AWS Lookout for Metrics, Azure Anomaly Detector, or Google Cloud's anomaly detection APIs handle the ML heavy lifting. These services are metered by data volume and add a manageable ongoing cost.
For streaming data (transactions, sensor readings), the detection runs as a background worker or serverless function that processes each event and writes alerts to a notifications queue. Alerts are then routed to the appropriate channel — email, SMS via Twilio, Slack, or in-app notification — based on severity and user preferences.
Questions to ask your developer
- What counts as "normal" for this metric, and how does the system learn it? The baseline is everything — a poorly defined baseline will produce either too many alerts or miss real issues.
- How do we tune sensitivity without a data scientist on call? Good implementations let administrators adjust thresholds through a UI rather than requiring a code change.
- Is detection real-time or batch? Real-time detection (within seconds) costs more to build and run than nightly batch processing — make sure you actually need real-time.
- How do users manage and acknowledge alerts? Alerts need a lifecycle — open, acknowledged, resolved — so teams don't work on the same incident twice.
- What happens to historical alerts? Keeping alert history is essential for audit trails and for tuning the system over time.
See also: AI chatbot · Audit trail · App cost calculator