> ## Documentation Index
> Fetch the complete documentation index at: https://docs.aiaxoniq.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Your first hour

> Once data is flowing: build a dashboard from a template, create and test an alert rule, see how a firing alert becomes an incident, and follow a problem from a log to a trace.

This page picks up where the [Quickstart](/get-started/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.

<Info>
  **Before you start.**

  * Telemetry is arriving and queryable — see
    [Verify your data arrived](/get-started/verify-data). 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](/concepts/roles).
  * Your services set `service.name`. Without it everything collapses into
    `unknown_service`, and per-service views are meaningless. See
    [Resource attributes](/send-data/otel/resource-attributes).
</Info>

<Tip>
  **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.
</Tip>

## 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.

<Steps>
  <Step title="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.
  </Step>

  <Step title="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.
  </Step>

  <Step title="Configure and create">
    Under **Create**, enter a **Dashboard name**, fill in any variables the
    template asks for, and select **Review**, then **Create dashboard**.
  </Step>
</Steps>

**Expected result:** the new dashboard opens, and it is listed under
**Dashboard → Saved dashboards**.

<Note>
  **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](/guides/dashboards/overview) for panels, versions and rollback.
</Note>

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.

<Steps>
  <Step title="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.
  </Step>

  <Step title="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.
  </Step>

  <Step title="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.
  </Step>

  <Step title="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**.
  </Step>

  <Step title="Test the saved rule">
    In the rules list, use the rule's **Send a test notification** action. Test
    messages are prefixed `[TEST]`.
  </Step>
</Steps>

**Expected result:** the rule appears in the list, the test message arrives in
your channel, and **Preview** gave the answer you expected.

<Warning>
  **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](/guides/alerts/overview) lists the supported rule types and
  comparators.
</Warning>

<Note>
  **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](/guides/alerts/overview).
</Note>

## 3. See how an alert becomes an incident

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

<Steps>
  <Step title="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.
  </Step>

  <Step title="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.
  </Step>

  <Step title="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.
  </Step>

  <Step title="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.
  </Step>
</Steps>

<Note>
  **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](/guides/incidents/overview) and
  [Silences and maintenance windows](/guides/alerts/silences-maintenance).
</Note>

## 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.

<Steps>
  <Step title="Find the log lines">
    Open **Logs → Explorer** and search for the error, the service or an id from
    the alert. [Searching logs](/guides/logs/search) has the query syntax.
  </Step>

  <Step title="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.
  </Step>

  <Step title="Read the trace">
    The waterfall shows where the time went and which hop failed. See
    [Exploring traces](/guides/traces/overview).
  </Step>

  <Step title="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](/guides/services/service-map).
  </Step>
</Steps>

<Warning>
  **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](/concepts/data-model).
</Warning>

### 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](/guides/ai/assistant) for what it does and what to check before
trusting its answer.

## Troubleshooting

<AccordionGroup>
  <Accordion title="The Create, New rule or Test controls are greyed out" icon="lock">
    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.
  </Accordion>

  <Accordion title="The test was not sent because the rule is silenced" icon="bell-slash">
    A silence covers the rule right now. You are asked whether to **Send
    anyway**; or wait for the silence to end.
  </Accordion>

  <Accordion title="The channel rejected the test" icon="triangle-exclamation">
    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.
  </Accordion>

  <Accordion title="The rule fired but no incident appeared" icon="circle-question">
    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.
  </Accordion>
</AccordionGroup>

## Next

<CardGroup cols={2}>
  <Card title="Invite your team" icon="users" href="/guides/settings/overview">
    Members, roles and invitations live in Settings.
  </Card>

  <Card title="Service level objectives" icon="bullseye" href="/guides/slos/overview">
    Alert on burn rate instead of on every blip.
  </Card>

  <Card title="Escalation policies" icon="stairs" href="/guides/alerts/escalation-policies">
    Who is paged next when nobody acknowledges.
  </Card>

  <Card title="Product tour" icon="compass" href="/get-started/product-tour">
    Every section of the product, and where to read about it.
  </Card>
</CardGroup>