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

# Onboarding: SaaS customer

> The full journey for a team using aiAxonIQ Cloud — from invitation to a team that opens it daily, in the order that avoids rework.

For a team using aiAxonIQ Cloud with services running on your own
infrastructure. This is the default path.

<Info>
  **Roughly an afternoon to something useful**, spread over a week to a team
  that opens it daily. The sequence below is ordered to avoid rework — steps 2
  and 3 in particular are cheap now and expensive to change once data has
  accumulated.
</Info>

## Day one

<Steps>
  <Step title="Accept your invitation and sign in">
    You become the Owner of your organization. Invitations expire after seven
    days — see [Create your account](/get-started/accounts).
  </Step>

  <Step title="Decide how you separate environments">
    Before sending anything. A `deployment.environment` resource attribute in
    one organization is what most teams want; a second organization is the
    answer only when the requirement is *access control*.

    Changing your mind later means re-tagging everything and losing continuity
    in every chart. See
    [Organizations and multi-tenancy](/concepts/organizations#separating-environments).
  </Step>

  <Step title="Agree service names">
    Ten minutes with your team, and it sets the vocabulary of every dashboard
    and alert you write afterwards. Use the name people say out loud, keep it
    identical across environments, and never encode the instance.

    See [Resource attributes](/send-data/otel/resource-attributes#naming-services).
  </Step>

  <Step title="Create a license key and prove the path">
    Run the [Quickstart](/get-started/quickstart) — ten minutes with `curl`.
    It proves network, credential, ingest and query before any collector or
    SDK is involved, so anything that fails afterwards is your instrumentation
    rather than your setup.
  </Step>

  <Step title="Install a Collector">
    Not an SDK first. A Collector gives you host and container telemetry
    immediately, changes nothing in your applications, and becomes the single
    place you later add filtering, redaction and sampling.

    [Docker](/send-data/platforms/docker) ·
    [Docker Compose](/send-data/platforms/docker-compose) ·
    [Linux](/send-data/platforms/linux) ·
    [Kubernetes](/send-data/platforms/kubernetes)
  </Step>

  <Step title="Instrument one service">
    One, not all of them. Auto-instrumentation, with `OTEL_SERVICE_NAME` and
    `deployment.environment` set. Confirm its traces, its logs and its
    service-map edges all look right before repeating the pattern.

    See [Instrument your application](/send-data/otel/zero-code).
  </Step>
</Steps>

## Week one

<Steps>
  <Step title="Instrument the rest of the path">
    Follow one real request end to end and instrument every service it touches.
    A complete trace across five services is worth far more than partial
    coverage of twenty.
  </Step>

  <Step title="Check your traces actually join">
    Open a trace and confirm it spans every service you expect. A hole means
    context propagation broke or sampling is inconsistent — see
    [Traces with a hole in them](/guides/traces/overview#traces-with-a-hole-in-them).
  </Step>

  <Step title="Set up alerting that will actually fire">
    Start with two or three rules, not twenty. Include one **absence** rule —
    it is the one that catches a crashed exporter, which no threshold on the
    data itself can detect.

    **Test every rule after saving it.** A rule saved with an unimplemented
    comparator is created without complaint and never fires. See
    [Alerting](/guides/alerts/overview).
  </Step>

  <Step title="Add a synthetic check on your front door">
    Everything else only exists if your code ran. A synthetic check tells you
    whether users can reach you at all. See
    [Synthetic monitoring](/guides/synthetics/overview).
  </Step>

  <Step title="Build one dashboard people will open">
    Start from a template and cut it down. A dashboard with six panels that
    everyone reads beats forty nobody does. See
    [Dashboards](/guides/dashboards/overview).
  </Step>
</Steps>

## Month one

<AccordionGroup>
  <Accordion title="Invite your team with the right roles" icon="users">
    Not everyone needs Admin. Viewer for most people, Editor for whoever
    maintains dashboards and alerts, Auditor for a compliance reviewer who must
    not be able to change anything. See
    [Roles and permissions](/concepts/roles).
  </Accordion>

  <Accordion title="Check your usage against your plan" icon="gauge">
    **Settings → Usage**, in the first month rather than the third. Exceeding a
    volume allowance does not stop your ingest, so you will not be warned by a
    failure — see [Plan limits](/concepts/limits).
  </Accordion>

  <Accordion title="Reduce volume before it becomes a bill" icon="filter">
    Drop health-check traffic at the Collector, raise log levels in noisy
    services, and check no metric label carries a user or request id. In that
    order — the first is usually the largest and costs you nothing you read.

    See [Reducing what you store](/concepts/retention#reducing-what-you-store).
  </Accordion>

  <Accordion title="Set one SLO" icon="bullseye">
    On your most important user-facing path. Accept a suggestion rather than
    inventing a number, and alert on burn rate rather than on breach. See
    [Service level objectives](/guides/slos/overview).
  </Accordion>

  <Accordion title="Index your runbooks" icon="book">
    The knowledge base answers questions from *your* documents rather than from
    general knowledge. It is worth an hour, and it is the difference between a
    generic answer and a useful one. See [AI features](/guides/ai/overview).
  </Accordion>
</AccordionGroup>

## The mistakes worth avoiding

<Warning>
  **Instrumenting everything before checking anything.** Instrument one
  service, verify it completely, then repeat. Twenty services instrumented
  identically wrong is twenty things to fix.
</Warning>

<Warning>
  **Building dashboards before setting service names.** Every panel you build
  against `unknown_service` has to be rebuilt.
</Warning>

<Warning>
  **Creating forty alert rules on day one.** Every rule that fires and is
  ignored trains your team to ignore the next one. Start with the handful you
  would genuinely get out of bed for.
</Warning>

## Next

<CardGroup cols={3}>
  <Card title="Docker" icon="docker" href="/onboarding/docker">
    If your services run in containers on a few hosts.
  </Card>

  <Card title="Kubernetes" icon="dharmachakra" href="/onboarding/kubernetes">
    If they run on a cluster.
  </Card>

  <Card title="Enterprise" icon="building-columns" href="/onboarding/enterprise">
    Many teams, single sign-on and a security review.
  </Card>
</CardGroup>