> For the complete documentation index, see [llms.txt](https://docs.sonarsource.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.sonarsource.com/sonarqube-server/server-installation/ai-agents/verifying-the-deployment.md).

# Verifying the deployment

In SonarQube Server 2026.5, confirm the Agent Orchestrator and Vortex analysis are reachable, then run a first agentic job end to end.

Work through these checks in order. Each one depends on the one before it, so a failure tells you where to look.

## Check component health <a href="#check-health" id="check-health"></a>

Go to **Administration** > **System**. SonarQube Server reports the health of the Agent Orchestrator and Vortex analysis there, alongside the rest of your instance. See [System info and server ID](/sonarqube-server/instance-administration/system-info-and-server-id.md) to check whether your agents are deployed.

SonarQube Server polls the Orchestrator, which reports the health of each agent runtime it can see. It polls Vortex analysis directly.

The System Info File and the Support Info File carry the same information, so attach one of those when you contact support.

| What you see                                       | What it means                                                               |
| -------------------------------------------------- | --------------------------------------------------------------------------- |
| The Orchestrator is healthy and reports each agent | The deployment is wired up correctly                                        |
| The Orchestrator is unreachable                    | SonarQube Server can't reach it. Check the address and the network path     |
| The Orchestrator is healthy but reports no agents  | The Orchestrator is running, but no runtime is reachable from it            |
| Vortex analysis is unreachable                     | The Remediation Agent runs in a degraded state, without verifying its fixes |

## Check the AI Capabilities page <a href="#check-ai-capabilities" id="check-ai-capabilities"></a>

Go to **Administration** > **Configuration** > **AI Capabilities**. If an agent is licensed and enabled but its components aren't reachable, this page says so and points you at what's missing.

This is also where you confirm an LLM provider and model are saved. Until they are, the enablement toggles stay locked.

## Run a first job <a href="#run-a-first-job" id="run-a-first-job"></a>

A successful health check proves the components can talk to each other. It doesn't prove a job can complete, because that also needs storage, the sandbox, and outbound access to your LLM provider to be working.

To confirm the whole path, trigger one job on a small project that's bound to a repository and has been analyzed:

* For the Remediation Agent, assign a single issue to the agent from the project's issues list. See [Backlog fix suggestions](/sonarqube-server/user-guide/issues/with-ai-features/backlog-fix-suggestions.md)
* For the Hunter Agent, wait for its next scheduled run, or trigger a run if your setup allows it

Then watch the job through to completion.

## Track jobs <a href="#track-jobs" id="track-jobs"></a>

Go to **Administration** > **Projects** > **Agentic tasks** to see agentic jobs and their status. You can filter by status, by agent, and by date range, in the same way you would on the background tasks page.

Each job has its own log, which you can download from the job. Use it to see what a job actually did, and why it failed if it did.

{% hint style="info" %}
Job logs cover the work of a single job. Logs from the containers themselves, unrelated to a specific job, aren't available through SonarQube Server, and the log level of the agent components cannot be changed from the UI. Read the container logs directly from your platform when you need that level of detail.
{% endhint %}

## What a healthy first run looks like <a href="#healthy-first-run" id="healthy-first-run"></a>

| Stage             | Sign it worked                                                                                        |
| ----------------- | ----------------------------------------------------------------------------------------------------- |
| Job accepted      | The job appears on the Agentic tasks page                                                             |
| Code staged       | Artifacts appear in your storage backend under the job                                                |
| Sandbox started   | A runtime container starts, and doesn't exit immediately                                              |
| Job ran           | The job log shows the agent's work rather than a configuration error                                  |
| Results processed | The Remediation Agent opens a pull request, or the Hunter Agent's findings appear in SonarQube Server |
| Cleaned up        | The runtime container is gone, and the staged code is removed                                         |

If the runtime container exits straight away, the sandbox is the most likely cause. See [Setting up the sandbox runtime](/sonarqube-server/server-installation/ai-agents/sandbox-runtime.md).

If the job fails while reading or writing artifacts, the problem is storage access or the outbound rules covering your storage endpoint. See [Setting up shared storage](/sonarqube-server/server-installation/ai-agents/shared-storage.md).

## Next step <a href="#next-step" id="next-step"></a>

With the deployment confirmed, enable the agents in the SonarQube Server UI. See [Remediation Agent](/sonarqube-server/instance-administration/ai-features/remediation-agent.md).

## Related pages <a href="#related-pages" id="related-pages"></a>

* [Troubleshooting](/sonarqube-server/server-installation/ai-agents/troubleshooting.md)
* [Installation overview](/sonarqube-server/server-installation/ai-agents/installation-overview.md)
* [Remediation Agent](/sonarqube-server/instance-administration/ai-features/remediation-agent.md)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.sonarsource.com/sonarqube-server/server-installation/ai-agents/verifying-the-deployment.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.