Server Health

Main Node is Inactive

The main node has been inactive for N minutes.

If this is a planned inactivity (a restart or upgrade), you can ignore this message — it will disappear once the main node is active again. Otherwise, please log in to the main node server and check the status of the TeamCity process.

If there is no TeamCity process or the server is down and cannot be recovered shortly, you can assign the " Main TeamCity node " responsibility to the current or some other node on the Nodes Configuration page.

Different Versions of Main and Secondary Servers

The secondary node version doesn't match the current server version.

In this case, you need to update the secondary node to the same version as of the main TeamCity Server.

No Proxy Server in Multinode Setup

Multinode setup doesn't have a proxy server.

To set up a high-availability TeamCity installation, you need to configure a reverse proxy.

Unassigned Responsibilities

TeamCity notifies you if none of the cluster nodes have a certain responsibility specific. For instance, if the "VCS repositories polling" responsibility is unchecked for all nodes, TeamCity cannot check repositories for changes and start new builds. Navigate to Administration | Node Settings and ensure each responsibility is assigned to at least one node.

Proxy Configuration Version Mismatch

TeamCity shows this warning when the value of the X-TeamCity-Proxy header declared in your proxy configuration indicates that the configuration is not fully compatible with your TeamCity server. Switch this documentation to the version that matches your TeamCity server and ensure your proxy settings are similar to these sample configurations: Proxy Configuration.

Server Root URL Uses HTTP

This report is shown when you configured the HTTPS access to TeamCity, but your server URL is still set to an "http://..." address. Update your server URL to dismiss this warning.

Domain Isolation Artifacts URL Uses HTTP

This report is shown when you configured the HTTPS access to TeamCity, but your artifacts isolation URL is still set to an "http://..." address. Update your artifacts isolation URL to dismiss this warning.

Proxy Server Configuration

If a reverse proxy is used in front of the TeamCity server, it needs to be configured to support the WebSocket protocol.

All URLs used by browsers that do not support the WebSocket connection are listed in the corresponding health report.

BIO Connector Adjustment

If Tomcat is configured to use the BIO connector, the WebSocket protocol is automatically disabled. It is recommended to change the Tomcat Connector settings to use the NIO connector.

Dependency problems

TeamCity detects build configurations dependent on a missing build configuration (for example, on a build configuration deleted after the dependency was configured).

Configurations with Large Build Logs

Large Build Logs (more than 200 MB by default) can reduce the server performance as they could be too heavy to parse and are hard to view in the browser.

The build script can be tuned to print less output if this inspection fails frequently for some build configuration.

Inefficient Artifacts Publishing

TeamCity detects a build publishing many small artifact files and suggests publishing them as a single .zip archive to optimize the upload/download operations. See more information here.

Duplicates Finder Runner

ReSharper Command Line Tools of version 2021.3 and newer no longer include the DupFinder tool. As a result, the Duplicates Finder (ReSharper) runner that relies on this tool cannot operate with CLT versions bundled with newest TeamCity installations.

To continue using this runner, install R# CLT of version 2021.2.3 or older, and choose this version under the runner's Advanced Settings.

Unused VCS Roots

TeamCity will show you the VCS roots defined in a project and will offer to delete the unused roots.

Similar VCS roots

TeamCity qualifies VCS roots as identical when their major settings (for example, URLs, branch settings) are the same even if some of their settings (for example, username, password) are different.

The report will show you identical roots and will leave it up to you whether to merge them or not.

Similar VCS Root Usages (AKA instances)

You can define values for VCS root settings or use parameter references to various parameters defined at different levels.

When the referenced VCS roots parameters are resolved to the same values as the values defined, such cases will be reported as identical VCS root usages.

The general recommendation is to use parameter references for root settings, thus optimizing the amount of VCS roots.

Trigger Rules for Unattached VCS roots

TeamCity displays a warning if a rule of a VCS Trigger or Schedule Trigger references a VCS root which is not attached to any build configuration.

Redundant Trigger

The report will show cases when a build trigger is redundant, for example:

• There are two build configurations A and B

• A snapshot depends on B

• Both have VCS triggers, A with the Trigger on changes in snapshot dependencies option enabled. In this case, the VCS trigger in B is redundant and causes builds of A to be put into the queue several times.

Multiple identical build triggers

The warning is displayed if there are two or more enabled triggers of the same type with identical sets of parameter values. Disabled triggers are not taken into account.

Effective Quiet Period is Bigger Than Specified

When a VCS trigger for a build configuration has a quiet period, TeamCity will wait the specified time after the last detected change before triggering the build. During this time, all VCS Roots which affect this build configuration are checked for changes. If other VCS Roots have checking for changes interval bigger than the quiet period, the effective quiet period will be equal to the maximum checking for changes interval of the involved VCS Roots (it could be a VCS Roots from the dependencies).

A possible fix could be one of the following:

• Use commit hooks to trigger checking for changes operations

• Increase quiet period in the VCS trigger so it is larger than checking for changes interval of the related VCS Roots

• Reduce checking for changes interval for the problematic VCS Roots

Possible Frequent Clean Checkout

This section of the report will show possible frequent clean checkout, which may be caused by the following two reasons:

Custom Checkout Directory

Build configurations having different VCS settings but the same custom checkout directory may lead to frequent clean checkouts, slowing down the performance and hindering the consistency of incremental sources updates.

Build Files Cleaner (Swabra) Settings

Enabling the Build files cleaner (Swabra) build feature in several build configurations may cause extra clean checkouts. This may happen if builds from these configurations alternately run on the same agents and have identical Version Control Settings or the same custom checkout directory specified.

Possible frequent clean checkout (Swabra case) server health report shows such incorrectly set up configurations grouped by Swabra settings.

Optimal recommended checkout

A report is shown for large server-side patches with a recommendation to switch to the agent-side checkout.

Default auto-checkout on agent

If the default agent-side checkout is not possible, TeamCity will display a corresponding health report item and will use the server\-side checkout.

Some agents cannot upgrade

The report helps to find agents which failed to upgrade. Build agent logs should help identify the cause of the issue.

Cloud Agents

If a user removes an image from a profile, a warning is displayed that the instances already started by TeamCity will not be automatically stopped.

Unused Build Agents

The report is displayed for the agents not used for 3 days and more, if

• you have more than 3 agents in your environment

• your agents have been registered for more than 3 days

• if the builds were run on the server during these 3 days