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

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

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 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
• 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

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.

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.

What a healthy first run looks like

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.

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.

Next step

With the deployment confirmed, enable the agents in the SonarQube Server UI. See Remediation Agent.

Related pages

• Troubleshooting

• Installation overview

• Remediation Agent