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

# Support

> How to get help with KAOP, what to gather before you ask, and which questions you can answer yourself in seconds.

When something in the Komodor Agentic Operation Platform (KAOP) does not behave the way you expect,
a small amount of preparation usually turns a long thread into a single message. This page explains
what to check first, what details make a report actionable, and how to reach the Komodor team.

## Answer it yourself first

Most reports resolve against one of four things, and all four are faster than a conversation.

<CardGroup cols={2}>
  <Card title="Troubleshooting" href="/reference/troubleshooting">
    Offline agents, `401` responses, empty knowledge search, triggers that do not fire, failing
    runs.
  </Card>

  <Card title="Limits & quotas" href="/reference/limits-quotas">
    Whether you have hit a cap. A `409` on agent creation is a quota, not a bug.
  </Card>

  <Card title="The run's own evidence" href="/manage-your-agents/run/runs-evidence">
    A failing run records what it received, which tools it called, and how each call ended.
  </Card>
</CardGroup>

<Tip>
  For fleet-shaped questions — "what is failing lately", "which agent is burning the most budget" —
  ask the built-in assistant in **Chat**. It answers against your own workspace, so you get your
  numbers rather than a general explanation.
</Tip>

## Reaching the Komodor team

Your Komodor contact — the person or channel that onboarded your team — is the route for everything
that is not self-service:

* Account, access, and membership questions.
* Enabling a module that is off for your workspace.
* Raising an adjustable limit.
* Configuring an embedding provider so knowledge search can index and retrieve.
* Deployment questions about where agents and the control plane run.

## What to include in a report

The difference between a slow report and a fast one is almost always identifiers. Gather these
before you write.

| Detail                                   | Where to find it                                                                                                                                                                  |
| ---------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Run id**                               | The run's detail page, and the monospace meta line on any card that references it. A run id is the single most useful thing you can send — its whole evidence trail hangs off it. |
| **Agent id**                             | The agent's detail panel in **Fleet**.                                                                                                                                            |
| **Account id**                           | **Settings → Account**, shown as `acct_…` alongside your workspace name and slug.                                                                                                 |
| **Timestamp and timezone**               | When you saw the behavior. Runs are timestamped, so this narrows the search immediately.                                                                                          |
| **What you expected, and what happened** | In that order, and separately. "The trigger did not fire" and "the run failed" need different investigations.                                                                     |
| **The exact error**                      | Copy the message verbatim, including any status code. KAOP shows failure reasons as reported rather than rewriting them, so the raw text is meaningful.                           |
| **Whether it is reproducible**           | Once, intermittently, or every time — and if every time, the smallest sequence that reproduces it.                                                                                |

<Warning>
  Do not paste credential values, API keys, or worker tokens into a report. KAOP never needs the
  secret to investigate — the credential's name and the agents bound to it are enough. If you believe
  a secret has been exposed, rotate it first and say so in the report.
</Warning>

## Reporting a specific class of problem

<AccordionGroup>
  <Accordion title="A run produced the wrong answer">
    Send the run id and say what the right answer would have been. A wrong answer is a quality
    question, not an availability one — grading it under
    [Evaluations](/manage-your-agents/optimize/evaluations) captures the judgment durably and gives
    the report something concrete to point at.
  </Accordion>

  <Accordion title="An agent will not come online">
    Work through the offline-agent section of
    [Troubleshooting](/reference/troubleshooting) first: the worker process, its outbound access to
    the control plane, its token, and its agent id account for nearly every case. If it survives all
    four, send the agent id and the worker's own startup logs.
  </Accordion>

  <Accordion title="A tool or integration call keeps failing">
    Send the run id and the name of the integration. The run's evidence records the failing tool
    span with the upstream error, which usually identifies whether the problem is the credential,
    the permission, or the upstream system.
  </Accordion>

  <Accordion title="Cost looks wrong">
    Say which figure looks wrong and over what window. Spend is built from what each run reports, so
    the answer is often that some runs carry no usage metadata — see
    [Agent spend attribution](/manage-your-agents/optimize/agent-spend-attribution) for how a run's
    cost is classified before you treat a gap as a defect.
  </Accordion>

  <Accordion title="A permission decision surprised you">
    Send the actor, the action, and the resource. Access decisions are recorded, so a denial that
    looks wrong can be traced to the rule that produced it — see
    [Audit log](/security-and-governance/controls/audit-log).
  </Accordion>
</AccordionGroup>

## Asking for a change rather than a fix

Some things are configuration rather than defects, and they are handled the same way — through your
Komodor contact:

* **A higher limit.** Several caps are adjustable per workspace. Check
  [Limits & quotas](/reference/limits-quotas) for which figure you are actually hitting first.
* **A module turned on.** Module enablement is per workspace; see
  [Modules → Overview](/modules-and-workflows/overview) for what is available.
* **An embedding provider.** Semantic search over your knowledge base needs one configured for your
  deployment.

## Next steps

<CardGroup cols={2}>
  <Card title="Troubleshooting" href="/reference/troubleshooting">
    The common failures, with the checks that resolve them.
  </Card>

  <Card title="Limits & quotas" href="/reference/limits-quotas">
    The enforced caps and what happens at each one.
  </Card>

  <Card title="What's new" href="/reference/changelog">
    Whether the behavior you are seeing changed recently.
  </Card>

  <Card title="Runs & evidence" href="/manage-your-agents/run/runs-evidence">
    How to read the trail a run leaves behind.
  </Card>
</CardGroup>


## Related topics

- [Troubleshooting](/reference/troubleshooting.md)
- [Operating a self-hosted install](/get-started/on-prem/operating.md)
- [What's new](/reference/changelog.md)
- [Limits & quotas](/reference/limits-quotas.md)
- [Agent spend attribution](/manage-your-agents/optimize/agent-spend-attribution.md)