Skip to main content
This page picks up where the Quickstart ends. Your telemetry is arriving; now you make the product useful. By the end you will have a dashboard, an alert rule you know works, and a route from “something is wrong” to the request that caused it.
Before you start.
  • Telemetry is arriving and queryable — see Verify your data arrived. Most steps below read real data and have nothing to show without it.
  • You have the Editor role or higher to create dashboards and alert rules. Sending a test notification needs Admin. See Roles and permissions.
  • Your services set service.name. Without it everything collapses into unknown_service, and per-service views are meaningless. See Resource attributes.
Get started keeps score for you. The Get started page under Manage ticks off “Build a dashboard” and “Set up an alert” as soon as one exists. It checks the account itself rather than remembering what you clicked, so a tick there means the thing is really there.

​
1. Build a dashboard from a template

A template gives you a working dashboard in a minute, which you then edit. The gallery also checks each template against what your account is already sending, so you can pick one that will show data straight away.
1

Open the template gallery

Go to Dashboard → Templates. The Ready for your data group lists the templates that match telemetry this account is already reporting.
2

Open a template

Choose one and select Use. The panel that opens shows its layout, the data sources it reads, and — for metric templates — which of its metrics are reporting in your account.Each template carries a badge: Data is reporting, Some data missing or No data yet. Pick one that says data is reporting for your first dashboard.
3

Configure and create

Under Create, enter a Dashboard name, fill in any variables the template asks for, and select Review, then Create dashboard.
Expected result: the new dashboard opens, and it is listed under Dashboard → Saved dashboards.
A dashboard made from a template is a copy. Editing it changes nothing else, and later changes to the template do not reach it. See Dashboards for panels, versions and rollback.
If a panel is empty, check the time range first, then whether the template reads a metric your account does not send. The badge and the metric list in the template panel say which one it is.

​
2. Create an alert rule, and prove it works

A dashboard only helps when someone is looking at it. An alert rule is what tells you when nobody is.
1

Start a new rule

Go to Alerts → Rules & history and select New rule. To avoid starting from nothing, choose an entry under Start from a template. It fills in the form, and nothing is created until you save.
2

Describe the condition

Set the Name, Type, Severity and the condition. For a first rule, Threshold is the simplest type. Add a Runbook URL if you have one — it goes out with every notification.
3

Preview it against live data

Select Preview. The rule is evaluated against your data as it is now, and you are told whether it would be firing or would not fire. Nothing is saved and nobody is notified.
4

Choose where it goes

Pick a Channel and fill in its Channel config. An Admin can select Send a test to this channel to deliver a real [TEST] message before anything is saved. Then select Create rule.
5

Test the saved rule

In the rules list, use the rule’s Send a test notification action. Test messages are prefixed [TEST].
Expected result: the rule appears in the list, the test message arrives in your channel, and Preview gave the answer you expected.
Test every rule after saving it. A rule can be saved and still never fire — for example with a comparator the evaluator does not support. Preview and Test together are the only way to tell a working rule from a decorative one. Alerting lists the supported rule types and comparators.
Generic outbound webhooks are off by default. If you choose the webhook channel and it is refused, that is why — pick another channel. See Alerting.

​
3. See how an alert becomes an incident

You do not create incidents by hand. They follow from alert rules.
1

The rule fires

Rules are checked every 60 seconds. When a rule’s condition starts to hold, and it is outside its cooldown and not silenced, it fires.
2

An incident opens

As the rule fires, an incident is opened for it under Incidents, before the notification is sent. One rule has at most one open incident at a time, so a problem that lasts does not pile up duplicates.
3

Someone takes it

On the incident, Acknowledge tells everyone else you are on it, and Assign hands it to a teammate. Both are recorded on the incident’s timeline.
4

It resolves

When the condition clears, the incident is resolved automatically. You can also Resolve it yourself. A resolved incident cannot be reopened — if the problem comes back, it opens a new incident with its own timings.
Three things do not open an incident: a test notification, a rule that is covered by a silence when it would fire, and a rule still inside its cooldown. Failing synthetic checks can open incidents too, in the same way. See Incidents and Silences and maintenance windows.

​
4. Investigate a problem

When an alert fires, you want to know which request failed and why. The route through the product is logs, then the trace, then the service map.
1

Find the log lines

Open Logs → Explorer and search for the error, the service or an id from the alert. Searching logs has the query syntax.
2

Jump to the trace

Expand a log line. If the line was written inside a traced request, the Investigate area shows View trace, which opens that request’s trace.
3

Read the trace

The waterfall shows where the time went and which hop failed. See Exploring traces.
4

Look at the neighbours

Open APM → Service map to see what calls the failing service and what it calls. You can filter the map by environment and version. See Services and the service map.
No View trace link on a log line means the line carries no trace context. That happens when the logger was not an OpenTelemetry-aware one. The line is still searchable, but it cannot link to a request. See Signals and the data model.

​
With the AI assistant

AI Assistant → Investigate runs an investigation for you across your telemetry. It needs a language model provider configured for your deployment. If none is configured, the rest of this page still works. Where one is configured, a new incident may also start an investigation on its own. See AI assistant for what it does and what to check before trusting its answer.

​
Troubleshooting

Your role does not allow it. Creating dashboards and rules needs Editor; sending a test notification needs Admin. The action buttons on a rule say which role they need when you hover them.
A silence covers the rule right now. You are asked whether to Send anyway; or wait for the silence to end.
The request reached aiAxonIQ and the channel refused it. The message shown is the channel’s own answer — usually a wrong webhook URL or key in the channel config.
Check the rule’s history under Alerts → Rules & history. If it shows the rule fired, open Incidents and widen the filters — an incident resolves automatically once the condition clears.

​
Next

Invite your team

Members, roles and invitations live in Settings.

Service level objectives

Alert on burn rate instead of on every blip.

Escalation policies

Who is paged next when nobody acknowledges.

Product tour

Every section of the product, and where to read about it.