Skip to main content
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.

Troubleshooting

Offline agents, 401 responses, empty knowledge search, triggers that do not fire, failing runs.

Limits & quotas

Whether you have hit a cap. A 409 on agent creation is a quota, not a bug.

The run's own evidence

A failing run records what it received, which tools it called, and how each call ended.
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.

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

​
Reporting a specific class of problem

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 captures the judgment durably and gives the report something concrete to point at.
Work through the offline-agent section of 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.
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.
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 for how a run’s cost is classified before you treat a gap as a defect.
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.

​
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 for which figure you are actually hitting first.
  • A module turned on. Module enablement is per workspace; see Modules → Overview for what is available.
  • An embedding provider. Semantic search over your knowledge base needs one configured for your deployment.

​
Next steps

Troubleshooting

The common failures, with the checks that resolve them.

Limits & quotas

The enforced caps and what happens at each one.

What's new

Whether the behavior you are seeing changed recently.

Runs & evidence

How to read the trail a run leaves behind.