An anomaly is an unusual observation or pattern that may indicate something important or abnormal. In machine learning and data analysis, an anomaly is a data point, event, behaviour or signal that differs from what is normally expected.

An anomaly is not automatically a mistake. It can be an error, but it can also be an important signal. A sudden increase in failed logins may indicate a cyberattack. A strange transaction may indicate fraud. A sensor reading outside the normal range may indicate equipment failure. A rare medical measurement may indicate a health problem. A sudden spike in website traffic may indicate a campaign success, a bot attack or a tracking issue.

This is why anomalies matter in machine learning. They often point to the cases that deserve attention. Most data may describe normal behaviour, but a small number of unusual observations may reveal risk, opportunity, error or change.

What anomaly means

An anomaly is an observation that differs from the expected pattern. The difference can appear in one value, several values, a sequence of events or the relationship between variables.

For example, a single unusually large payment may be an anomaly. A normal payment amount from an unusual location may also be an anomaly. A website visit may look normal by itself, but become suspicious if it happens after many failed login attempts.

This is why the meaning of anomaly depends on context. A temperature of 38 °C is normal for hot weather, but abnormal for a server room. A purchase of 2 000 EUR may be normal for a B2B customer, but unusual for a consumer account that usually spends 20 EUR.

A simple example of an anomaly

Imagine a website that usually receives 5 000 visits per day. One day, it receives 60 000 visits. That is an anomaly.

The anomaly does not tell us the cause by itself. It may be a successful campaign, a viral article, bot traffic, tracking duplication, a DDoS attempt or a reporting error. The unusual pattern is only the first signal. It needs investigation.

This is a key rule: anomaly detection can point to something unusual, but it does not automatically explain why it happened.

Anomaly vs outlier

The words anomaly and outlier are often used together. In many practical contexts, they mean almost the same thing: an unusual observation that differs from the rest of the data.

There is a small practical difference in how people often use the terms:

• Outlier – often describes a data point that is far away from other values in a statistical sense.
• Anomaly – often suggests that the unusual observation may have operational meaning and should be investigated.

For example, a very high transaction amount may be an outlier in a dataset. If it may indicate fraud, it becomes an anomaly worth investigating.

The distinction is not strict. Many libraries, papers and tools use anomaly detection and outlier detection as related or overlapping terms.

Anomaly vs normal variation

Not every unusual-looking value is a real anomaly. Data always contains natural variation.

For example, sales may be higher on weekends, support tickets may rise after a product release and website traffic may increase during a campaign. These patterns may look unusual if you compare them to the wrong baseline, but they may be normal for that context.

An anomaly should be unusual relative to a meaningful expectation. That expectation may depend on seasonality, user segment, business cycle, location, product category, time of day or other context.

Anomaly detection

Anomaly detection is the process of finding unusual observations or patterns in data. It can be done manually, with statistical rules, with machine learning or with specialised monitoring systems.

The goal is to identify cases that differ enough from normal behaviour to deserve attention. The result may be an alert, a risk score, a flagged transaction, a monitoring event, a fraud review or a data quality warning.

Anomaly detection is used in many areas:

• fraud detection – unusual transactions, logins or account behaviour,
• cybersecurity – abnormal network traffic, access patterns or system behaviour,
• manufacturing – sensor readings that may indicate equipment failure,
• healthcare – unusual lab values or physiological signals,
• finance – suspicious trades, payment patterns or reporting errors,
• marketing analytics – traffic spikes, conversion drops or campaign anomalies,
• software monitoring – latency spikes, error rates or unusual resource use,
• data quality – impossible values, duplicated events or tracking problems.

Why anomalies matter

Anomalies matter because they can reveal something that the average hides. Most dashboards and reports focus on normal patterns. Anomalies point to exceptions.

Those exceptions can be negative. A spike in failed payments may indicate a broken checkout. A sudden drop in conversions may indicate a tracking issue. An unusual login pattern may indicate account takeover.

But anomalies can also be positive. A sudden increase in demand may indicate a successful campaign. A product unexpectedly selling well in one region may reveal a new market opportunity. A content page receiving unusual organic traffic may show a new SEO opportunity.

Point anomalies

A point anomaly is a single observation that is unusual compared with the rest of the data.

For example, one transaction of 50 000 EUR may be unusual if the account usually spends less than 100 EUR. One sensor reading may be abnormal if it is far outside the expected range. One website session may be suspicious if it contains impossible navigation behaviour.

Point anomalies are often easier to understand because the unusual value is visible in one place. But they can still be difficult to classify correctly if the context is missing.

Contextual anomalies

A contextual anomaly is unusual only in a specific context. The value itself may be normal in general, but abnormal for the situation.

For example, 30 °C is normal outside in summer, but abnormal inside a refrigerated warehouse. A high number of orders may be normal on Black Friday, but unusual on a quiet Monday. A login at 3:00 may be normal for a night-shift employee, but suspicious for an office worker who normally logs in only during business hours.

Contextual anomalies are important because many real-world systems depend on time, location, user type, seasonality and business rules.

Collective anomalies

A collective anomaly is a group of observations that becomes unusual together, even if individual observations do not look strange alone.

For example, one failed login attempt is normal. Fifty failed login attempts from different locations within a few minutes may be abnormal. One small refund may be normal. A pattern of many small refunds across related accounts may indicate fraud.

Collective anomalies are common in cybersecurity, fraud detection, monitoring and time series analysis. They require looking at sequences and relationships, not only individual data points.

Anomaly in time series data

Time series data is data ordered over time: traffic, sales, temperature, CPU usage, transactions, sensor readings, signups, conversions or error rates.

An anomaly in time series data may be a spike, drop, level shift, trend change, unusual seasonality or unexpected pattern. For example, a sudden drop in website conversions may indicate a checkout bug. A slow increase in server memory usage may indicate a memory leak.

Time series anomaly detection is difficult because normal behaviour often changes by hour, day, week, season or event. A value can be normal on Monday morning but abnormal on Sunday night.

Anomaly in tabular data

In tabular data, an anomaly may appear as an unusual row, an unusual combination of values or an impossible value.

For example, a customer age of 250 is likely a data quality anomaly. A transaction from a familiar card but an impossible country-time combination may be suspicious. A product with a negative price may indicate an input error.

Tabular anomaly detection often needs feature engineering, business rules, statistical checks and machine learning models. The best approach depends on whether labels are available and what type of anomaly matters.

Anomaly in images

In image data, an anomaly may be a visual defect, unusual object, damaged product, medical abnormality or unexpected pattern.

For example, a manufacturing system may inspect product images and flag scratches, cracks or missing parts. A medical imaging system may flag unusual tissue patterns for review. A security system may flag unusual objects in restricted areas.

Image anomalies can be subtle. They may involve texture, shape, position, colour or absence of an expected part. Machine learning can help, but human review is often needed in high-impact contexts.

Anomaly in text

In text data, an anomaly may be an unusual phrase, suspicious email, strange customer message, policy-violating content, toxic comment, spam pattern or unexpected document structure.

Text anomalies are harder to define because language is flexible. A rare sentence may be harmless. A common phrase may be suspicious in a certain context.

Embeddings can help represent text numerically so that unusual semantic patterns can be detected. But similarity in embedding space is not the same as correctness or risk. Results still need evaluation.

Anomaly and machine learning

Machine learning can help detect anomalies when manual rules are not enough. A model can learn what normal data usually looks like and then flag observations that differ from that pattern.

Some anomaly detection systems are supervised. They learn from labelled examples of normal and abnormal cases. Others are unsupervised. They try to identify unusual observations without labelled anomaly examples. A third type is semi-supervised or novelty detection, where the model learns mostly from normal data and flags new observations that do not fit.

This matters because real anomalies are often rare. In many areas, there are not enough labelled abnormal examples to train a normal supervised classifier.

Supervised anomaly detection

Supervised anomaly detection uses labelled data. The training data contains examples marked as normal and abnormal.

This can work well when many reliable labels exist. For example, a fraud detection model may learn from historical transactions where confirmed fraud is known. A quality inspection model may learn from images labelled as defective or non-defective.

The limitation is that labelled anomalies may be rare, incomplete or outdated. A model trained on known fraud patterns may miss new fraud strategies. A model trained on old machine failures may miss a new failure mode.

Unsupervised anomaly detection

Unsupervised anomaly detection tries to find unusual observations without labelled anomaly examples.

The model looks for points that are rare, isolated, far from dense regions or difficult to reconstruct. This is useful when anomalies are unknown or too rare to label.

Common unsupervised methods include clustering-based approaches, density-based methods, Isolation Forest, Local Outlier Factor and autoencoder-based methods.

The limitation is that unsupervised methods can flag unusual observations that are not actually important. Human review and business context are often needed.

Novelty detection

Novelty detection is similar to anomaly detection, but the training setup is slightly different.

In novelty detection, the model is trained on data that is assumed to represent normal behaviour. Then it checks whether new observations are different enough to be considered novel or abnormal.

This is useful when normal examples are available but abnormal examples are rare. For example, a manufacturing system may train on normal product images and then flag products that look different.

Anomaly detection and thresholds

Most anomaly detection systems need a threshold. The model may produce an anomaly score, and the threshold decides which observations are flagged.

A strict threshold flags fewer cases but may miss real anomalies. A loose threshold catches more suspicious cases but creates more false positives.

The right threshold depends on the cost of missing an anomaly and the cost of reviewing false alarms. Fraud detection, medical screening, system monitoring and marketing analytics may all need different threshold settings.

False positives

A false positive happens when a normal observation is incorrectly flagged as an anomaly.

False positives are common in anomaly detection because unusual does not always mean harmful. A loyal customer may make a larger purchase than usual. A server may spike during a legitimate campaign. A user may log in from a new country while travelling.

Too many false positives create alert fatigue. People stop trusting the system and may ignore important warnings.

False negatives

A false negative happens when a real anomaly is missed.

This can be serious. A fraud transaction may pass undetected. A machine failure warning may be missed. A security incident may continue without response. A data quality issue may corrupt reporting.

Reducing false negatives often means increasing sensitivity, but that can increase false positives. Anomaly detection is usually a trade-off between catching more problems and creating too many alerts.

Anomaly score

An anomaly score is a number that indicates how unusual an observation appears to be.

Different methods calculate anomaly scores differently. A distance-based method may score points by how far they are from neighbours. A density-based method may score points by how isolated they are. An autoencoder may score points by reconstruction error.

The score is useful for ranking cases. Instead of treating every alert equally, teams can review the highest-risk anomalies first.

Isolation Forest

Isolation Forest is a popular anomaly detection algorithm. It works by isolating observations through random splits.

The basic idea is that anomalies are easier to isolate than normal points. If a data point is very different from the rest, fewer random splits may be needed to separate it.

Isolation Forest is often used for tabular data and unsupervised anomaly detection. It can work well as a practical baseline, but it still requires careful feature preparation, threshold selection and validation.

Local Outlier Factor

Local Outlier Factor, often shortened to LOF, is a density-based anomaly detection method.

It compares the local density around one observation with the density around its neighbours. If a point is in a much lower-density region than nearby points, it may be considered an outlier.

This is useful because some anomalies are local. A value may not be extreme globally, but it may be unusual compared with similar observations.

Clustering and anomalies

Clustering groups similar observations together. Anomalies may appear as points that do not belong clearly to any cluster, are far from cluster centres or form very small unusual clusters.

For example, customer behaviour may form several normal groups. A customer who does not match any group may deserve review. A tiny cluster of unusual transactions may indicate a specific fraud pattern.

Clustering can help discover structure, but it does not automatically identify meaningful anomalies. Small clusters can be important, but they can also be noise.

Autoencoders and anomalies

An autoencoder is a neural network that learns to compress data and reconstruct it. It can be used for anomaly detection by learning to reconstruct normal examples well.

If an input is normal, the autoencoder should reconstruct it with low error. If an input is unusual, the reconstruction may be worse. The reconstruction error can then become an anomaly score.

This approach is common in images, sensor data, time series and other complex datasets. But it must be validated carefully. A model that is too flexible may reconstruct anomalies too well. A model that is too constrained may flag too many normal cases.

Bottleneck and anomalies

The bottleneck is the narrow part of an autoencoder that forces compression. It can help anomaly detection because the model cannot pass every detail through unchanged.

If the autoencoder learns normal structure through the bottleneck, unusual inputs may not compress and reconstruct as well. This can make anomalies easier to detect.

But the bottleneck must be chosen carefully. Too small a bottleneck may lose important normal information. Too large a bottleneck may allow the model to copy unusual inputs too easily.

Sparse autoencoders and anomalies

A sparse autoencoder is encouraged to use only a small number of active latent units. This can help create more selective representations.

For anomaly detection, sparse representations can be useful because normal inputs may activate familiar feature combinations, while unusual inputs may activate rare or unstable combinations.

However, sparsity is not a guarantee. A sparse autoencoder still needs proper validation, thresholding and monitoring. A sparse representation can be useful, but it is not automatically correct.

PCA and anomalies

PCA, or principal component analysis, can also help with anomaly detection. PCA reduces numerical data into principal components that preserve a large part of the variance.

An observation may be anomalous if it has unusual component scores or if it is poorly reconstructed from the selected components. This can help detect unusual structure in high-dimensional numerical data.

PCA can be useful as a simple and interpretable baseline. But it is linear and sensitive to scaling and outliers. It may miss complex nonlinear anomalies.

Dimensionality reduction and anomalies

Dimensionality reduction can help visualise and inspect anomalies in high-dimensional data.

Methods such as PCA, t-SNE or UMAP can project complex data into two or three dimensions. This may reveal clusters, isolated points or unusual groups.

However, visualisation is not proof. A point that looks isolated in a 2D projection may not be truly anomalous in the original space. Reduced visualisations should be treated as investigative tools, not final evidence.

Anomaly and data quality

Some anomalies are not real-world events. They are data quality problems.

Examples include impossible ages, negative prices, duplicate events, missing timestamps, corrupted sensor values, invalid country codes, broken tracking parameters or repeated transactions caused by system errors.

Data quality anomalies are important because they can damage reporting and machine learning models. A model trained on corrupted data may learn wrong patterns. A dashboard based on duplicated events may lead to bad business decisions.

Anomaly and data leakage

Data leakage happens when a model receives information during training that would not be available in real use. Anomaly detection systems can also suffer from leakage.

For example, if thresholds are tuned on test data, performance may look too good. If future information is used to detect past anomalies, the evaluation becomes unrealistic. If preprocessing learns from the whole dataset before splitting, test information can influence training.

The correct workflow depends on the task, but the principle is the same: evaluate anomaly detection as it would work in real use.

Anomaly and overfitting

Overfitting happens when a model learns training data too closely and performs poorly on new data. Anomaly detection models can overfit too.

A model may learn the exact normal patterns in the training dataset but fail when normal behaviour changes. It may flag harmless new patterns or miss new types of anomalies.

This is especially common when the training data is too narrow, the model is too complex or the evaluation does not include realistic future data.

Anomaly and model explainability

Model explainability is important in anomaly detection because people need to understand why something was flagged.

A fraud analyst, engineer, doctor, marketer or security specialist usually cannot act only on a black-box score. They need to know which feature, behaviour, time period or pattern made the observation unusual.

Explainability can reduce false alarms, improve trust and help teams respond correctly. If the model cannot explain its alerts, people may ignore them or overreact to them.

Anomaly and AI risk management

AI risk management uses anomaly detection in several ways. Anomalies can indicate model failures, data drift, misuse, security attacks or operational problems.

For example, a sudden change in model input distribution may indicate that the real world has changed. A spike in rejected outputs may indicate a prompt injection campaign. A sudden increase in hallucinated answers may indicate a retrieval problem.

Anomaly monitoring is therefore useful not only for business data, but also for AI systems themselves.

Anomaly and AI governance

AI governance defines rules, processes and controls for safe, auditable and accountable AI use. Anomaly detection can support governance by making unusual system behaviour visible.

For example, governance may require monitoring unusual tool calls by AI agents, unexpected access to sensitive documents, abnormal model outputs, unusual user behaviour or sudden changes in performance.

But anomaly detection is only one control. Governance also requires ownership, documentation, review, access control, incident response and human oversight.

Anomaly and prompt injection

Prompt injection is an attack or failure mode where external content tries to manipulate an AI system’s instructions.

Anomaly detection can help identify suspicious prompt patterns, unusual tool calls, unexpected data access or abnormal output behaviour. For example, if an AI assistant suddenly tries to access documents unrelated to the user’s task, that may be an anomaly worth investigating.

However, anomaly detection cannot fully prevent prompt injection. It should be part of layered defence with least privilege, tool validation, input handling, output checks and human approval for sensitive actions.

Anomaly and RAG systems

RAG, or retrieval-augmented generation, combines document retrieval with generated answers.

Anomalies in RAG systems may include retrieval of unrelated documents, sudden changes in source mix, missing citations, repeated unsupported answers, unusual embedding similarity scores or access to documents outside the user’s permission scope.

Monitoring these anomalies can help detect retrieval problems, stale sources, permission errors or prompt injection attempts.

Anomaly and embeddings

Embeddings can be used to detect unusual content, users, products or documents. If an item appears far away from normal clusters in embedding space, it may be unusual.

For example, a product description may be anomalous if it does not resemble any existing category. A support ticket may be unusual if it is semantically far from known issue types. A document may be suspicious if it looks unlike other documents in the same workflow.

But embedding-based anomaly detection must be validated carefully. A semantic outlier may be meaningful, but it may also be a formatting difference, language difference or representation artefact.

Anomaly in cybersecurity

Cybersecurity is one of the most common domains for anomaly detection. Security teams look for behaviour that differs from normal user, device or network activity.

Examples include unusual login times, impossible travel, abnormal data downloads, rare command execution, unexpected network traffic, sudden privilege use or unusual API calls.

Anomaly detection is useful because attackers often behave differently from legitimate users. But it also creates false positives because legitimate behaviour can change. A user travelling, changing job role or using a new device may look suspicious even when nothing malicious is happening.

Anomaly in fraud detection

Fraud detection often depends on finding unusual patterns.

Examples include unusual transaction amounts, purchases in unexpected locations, repeated small payments, sudden account changes, mismatched device behaviour or transactions that do not match a customer’s history.

Fraud anomalies are difficult because attackers adapt. A fraud detection model must be monitored and updated because yesterday’s known fraud pattern may not be tomorrow’s attack.

Anomaly in marketing analytics

In marketing analytics, anomalies often show that something changed.

A sudden traffic spike may indicate a viral post, bot traffic or tracking duplication. A conversion drop may indicate a landing page bug, checkout issue or campaign mismatch. A sudden change in source/medium data may indicate tagging problems. An unusual increase in direct traffic may indicate attribution loss.

Marketing anomalies should be investigated before conclusions are drawn. The same pattern can have several causes.

Anomaly in monitoring and observability

Software monitoring systems use anomaly detection to find unusual behaviour in logs, metrics and traces.

Examples include latency spikes, error-rate increases, abnormal CPU usage, memory leaks, queue growth, missing events or unusual traffic patterns.

This helps teams detect incidents earlier than static thresholds alone. A value may be technically below a fixed threshold but still unusual for that system at that time.

Anomaly and baseline

A baseline is the expected normal behaviour. Anomaly detection depends heavily on the baseline.

The baseline may be a historical average, rolling window, seasonal pattern, peer group, user profile, model prediction or business rule.

A weak baseline creates weak detection. For example, comparing Monday traffic to Sunday traffic may create false alerts. Comparing December sales to January sales without seasonality may also be misleading.

Anomaly and drift

Data drift happens when the distribution of input data changes over time. Concept drift happens when the relationship between inputs and outcomes changes.

Anomaly detection can help detect drift, but drift can also make anomaly detection harder. If normal behaviour changes gradually, the model may keep flagging normal new behaviour as abnormal.

This is why anomaly detection systems should be monitored and recalibrated. Normal is not always permanent.

Anomaly and rare events

Anomalies are often rare, but rare does not always mean abnormal.

A rare customer segment may be legitimate. A rare product combination may be normal for a niche use case. A rare medical measurement may be expected for a specific diagnosis. A rare search query may be valuable long-tail behaviour.

This is why anomaly detection should not simply punish rarity. It should consider context, risk and usefulness.

Anomaly and business context

Business context is essential because an algorithm does not know what matters by default.

A transaction may be statistically unusual but commercially normal. A traffic spike may be unusual but expected after a TV campaign. A low conversion rate may be normal for an awareness campaign but abnormal for branded search.

Human expertise often decides whether an anomaly is important. The model can flag. The analyst interprets.

How to investigate an anomaly

A useful anomaly investigation should be systematic. The goal is to avoid jumping to conclusions.

1. Confirm the anomaly – check whether the pattern is real or caused by bad data.
2. Check the baseline – compare against the right time period, segment or expected pattern.
3. Segment the data – inspect device, source, location, product, user group or channel.
4. Check recent changes – campaigns, releases, tracking changes, model changes or vendor updates.
5. Look for related signals – logs, errors, user reports, revenue, conversions or security alerts.
6. Assess impact – decide whether the anomaly is harmless, useful or risky.
7. Document the cause – record what happened and how it was handled.
8. Update monitoring – improve rules, thresholds or models if needed.

Common mistakes with anomalies

Anomalies are easy to notice but easy to misinterpret.

• Assuming every anomaly is bad – some anomalies are opportunities or valid rare cases.
• Ignoring context – time, segment, seasonality and business rules matter.
• Using fixed thresholds only – static thresholds may miss subtle but important changes.
• Trusting model scores blindly – anomaly scores need interpretation.
• Creating too many alerts – false positives cause alert fatigue.
• Missing collective anomalies – the pattern may be abnormal only across a group of events.
• Forgetting data quality – an anomaly may be caused by tracking or pipeline errors.
• Not documenting investigations – teams repeat the same analysis again later.
• Not updating the baseline – normal behaviour changes over time.

When anomalies are useful

Anomalies are useful when the unusual pattern points to something worth investigating.

They are especially useful in:

• fraud detection – identifying suspicious behaviour before loss grows,
• security monitoring – detecting compromise before full attack impact,
• data quality control – catching broken pipelines or impossible values,
• business monitoring – spotting sudden drops or spikes,
• system reliability – detecting incidents before users complain,
• manufacturing – finding defects or machine problems early,
• healthcare support – flagging unusual measurements for expert review,
• AI operations – monitoring drift, misuse, hallucinations and abnormal tool use.

When anomalies can mislead

Anomalies can mislead when they are treated as proof rather than evidence.

A model may flag unusual but harmless behaviour. A dashboard may highlight a spike caused by tracking duplication. A security system may alert on legitimate travel. A business team may overreact to normal seasonality.

Good anomaly detection therefore needs investigation, explanation and feedback. The system should learn which alerts were useful and which were noise.

How to remember anomaly

An anomaly can be remembered as “something that does not fit the expected pattern”.

That difference may be a problem, an opportunity, an error or a warning. The anomaly itself is not the final answer. It is the reason to look more closely.

In machine learning, anomaly detection helps find rare or unusual observations that normal averages may hide. But the model must be evaluated carefully because unusual does not always mean important, and important does not always look extreme.

Related terms

• Machine learning – the broader field in which models learn patterns from data and use them for predictions, classifications or decisions.
• Outlier – a data point that differs strongly from other observations. Outliers and anomalies are often closely related.
• Anomaly detection – the process of identifying unusual observations, events or patterns in data.
• Novelty detection – detecting new observations that do not fit a model trained on normal data.
• False positive – a normal case incorrectly flagged as anomalous.
• False negative – a real anomaly that the system fails to detect.
• Anomaly score – a numerical score that indicates how unusual an observation appears to be.
• Baseline – the expected normal behaviour used for comparison.
• Drift – a change in data distribution or relationships over time.
• Clustering – grouping similar observations together. Anomalies may appear as isolated points or unusual small groups.
• Autoencoder – a neural network that learns to compress data and reconstruct it. Reconstruction error can be used for anomaly detection.
• Bottleneck – the narrow part of an autoencoder that forces compression.
• Sparse autoencoder – an autoencoder encouraged to use only a small number of active latent units.
• PCA – principal component analysis – a dimensionality reduction method that can also help inspect unusual patterns in numerical data.
• Dimensionality reduction – reducing data into fewer dimensions. It can help visualise anomalies, but should not be treated as final proof.
• Embedding – a numerical representation of content. Embeddings can be used to compare similarity and find unusual semantic patterns.
• Model explainability – the ability to understand why a model produced a certain output or score.
• Data leakage – a situation where a model receives information during training that would not be available in real use.
• Overfitting – a model learning training data too closely and performing poorly on new data.
• RAG – retrieval-augmented generation. Anomaly monitoring can help detect unusual retrieval or answer behaviour.
• Prompt injection – an attack or failure mode where external content tries to manipulate a model’s instructions.
• AI risk management – identifying, measuring, controlling and monitoring risks created by AI systems.
• AI governance – rules, processes and controls for safe, auditable and accountable AI use.

Sources and further reading

• Novelty and Outlier Detection – scikit-learn.org – June 2026 – explains anomaly detection through outlier detection and novelty detection, including the difference between unsupervised and semi-supervised settings.
• Outlier detection with Local Outlier Factor – scikit-learn.org – June 2026 – shows how Local Outlier Factor detects samples with substantially lower local density than their neighbours.
• IsolationForest – scikit-learn.org – June 2026 – technical documentation for Isolation Forest, including anomaly scores and inlier/outlier interpretation.
• What Is Anomaly Detection? – ibm.com – June 2026 – explains anomaly detection as identifying observations, events or data points that deviate from what is usual, standard or expected.
• Anomaly Detection in Machine Learning – ibm.com – June 2026 – describes anomaly detection as defining normal patterns and identifying data points that fall outside normal behaviour.
• Anomaly detection overview – docs.cloud.google.com – June 2026 – Google BigQuery documentation describing anomaly detection as identifying data deviations in a dataset.
• Detecting Abnormal Cyber Behavior Before a Cyberattack – nist.gov – June 2026 – NIST article explaining behavioural anomaly detection as monitoring systems for unusual events or trends.
• Time Series Anomaly Detection – research.google – June 2026 – Google Research publication describing machine learning and statistical approaches to detecting anomalous drops in noisy periodic traffic patterns.
• Benchmarking Unsupervised Strategies for Anomaly Detection in Multivariate Time Series – arxiv.org – June 2026 – research paper on unsupervised strategies for anomaly detection in time series, including transformer-based approaches.