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.
Your telemetry stays inside your organization. These features run in a service reachable only by the aiAxonIQ API, on your behalf, scoped to your organization — the same isolation as every other query. See Platform architecture.

​
What is available

Anomaly detection

Statistical outliers in a metric over a recent window, by Z-score and interquartile range. 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 and interquartile-range 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.Also note that anomaly alert rules are fired by the AI service, not by the main alerting loop. Creating one as an ordinary rule and expecting the evaluator to run it will not work — nothing evaluates it and it silently never fires. 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.
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.

​
Feedback

Most surfaces accept a thumbs up or down. It is recorded against your organization and is how these features improve. It is worth the two seconds: the alternative is that nobody finds out a suggestion was wrong.

​
Next

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.