Skip to main content
aiAxonIQ runs a set of AI features over your telemetry. They are assistive: each produces a starting point that is faster than doing it by hand, and each can be wrong in a way you should be able to recognise.
Every AI feature is scoped to your organization. They run in a service reachable only by the aiAxonIQ API, on your behalf, with the same tenant isolation as every other query. See Platform architecture.Model-backed features send data to a model provider. Anomaly detection and forecasting are statistical and run entirely inside the platform. Natural-language query, incident analysis, the knowledge base and the Assistant send your question and the telemetry excerpts they work from to the model provider your deployment is configured with. See Configuring AI providers.

​
What is available

Anomaly detection

Statistical outliers in a metric over a recent window, by Z-score. Fast, explainable, no training.

Forecasting

Where a series is heading, with seasonality. Capacity planning and error-budget projection.

Natural-language query

A question in English becomes a query over your telemetry.

Incident analysis

Give it a log excerpt from an incident; get a summary and likely causes.

Knowledge base

Index your own runbooks and postmortems, then get answers grounded in them.

Suggestions

Proposed alert rules and SLOs derived from how your services actually behave.

​
Anomaly detection

Z-score outlier detection over a recent window.
Statistical, not learned. There is no model to train and no warm-up period, and a flagged point can always be traced back to how far it sat from the recent distribution. That is a real advantage over an opaque score: you can tell whether to believe it.
An anomaly is a deviation, not a problem. A deploy, a marketing campaign or a planned batch job is anomalous and entirely fine. Treat output as “something changed here”, not as an incident.Anomaly alert rules are evaluated by the ordinary 60-second alerting loop, which asks this service for a score once per sweep. They fire, resolve, respect cooldowns and route to channels exactly like a threshold rule; what differs is that the rule carries a z-score cutoff rather than a bound, and reports how many points in the window were anomalous. See Alerting.

​
Forecasting

Projects a metric forward, accounting for seasonality — daily and weekly cycles rather than a straight line through the average. Use it for capacity questions (“when do we run out of disk”) and for error budgets (“do we exhaust before the window ends”).
Forecasting is rate limited, because fitting a model is seconds of compute rather than milliseconds. If you are driving it from a script, expect to be throttled and space the calls out.
A forecast assumes the future resembles the past. It cannot know about the launch next week or the customer who churned yesterday. It is a projection of the current trend, and it is at its least reliable exactly when something has just changed.

​
Natural-language query

Ask a question in English; get a query over your telemetry and its result. The generated query is constrained before it runs and executes under a per-organization identity, so a generated query cannot read another organization’s data regardless of what it asks for.
Read the query it generated before trusting the number. The failure mode is not a refusal — it is a plausible query that answers a slightly different question than the one you asked, and returns a confident number for it.Natural-language query is at its best for exploration and for learning the data model. For anything that goes in a report, check the query.

​
Incident analysis

Supply a log excerpt from an incident and get a summary and likely causes. Runs are saved, so an analysis can be reopened later — useful when writing the postmortem a week afterwards.
The log excerpt is the input. A request without one is refused rather than answered generically: an analysis with nothing to analyse would be fluent and worthless.

​
Knowledge base

Index your own documents — runbooks, postmortems, architecture notes — and ask questions answered from them rather than from general knowledge. This is what makes answers specific to your system. “How do we roll back the payments service” has a real answer only if the runbook that describes it has been indexed.
The knowledge base needs an embedding model. It currently works only when the deployment’s model provider is OpenAI. With any other provider, documents are neither stored nor ranked, and the API says so rather than returning empty answers.
Indexing writes to a corpus shared across your whole organization, so it requires the Editor role. Anyone in the organization can then search it. Do not index a document you would not show to every member.

​
Suggestions

Alert rules and SLOs proposed from observed behaviour, which you accept or dismiss. A suggestion derived from what a service actually does is a far better starting point than a threshold picked because it was a round number. Accepting one creates an ordinary rule or objective — there is nothing special about it afterwards.

​
Next

AI Assistant and Investigate

The model-backed investigation surfaces, and what each needs.

LLM observability

Monitoring your AI workloads — a different thing to this page.

Alerting

Where suggestions land, and how rules actually evaluate.

Service level objectives

Error budgets and forecasting them.