Operations guide

This guide is for the technology team that operates the NeoLoad environment after deployment. It covers how to keep the system healthy, how to troubleshoot failures, and how to plan for maintenance. It doesn't cover how to create or run tests. For that, see the get started guide.

This topic adds the operational layer on top of your existing setup: what to monitor, how to create backups, and what to do when something breaks.

Monitor system health

Regular monitoring helps you catch problems before they affect test runs. Check the following components on a regular basis:

Controller

Monitor the following on the controller server:

  • CPU and memory use. A controller that runs out of resources during a test can lose data or crash the test.

  • Disk space. The controller stores test results locally while the test runs. If the disk runs out of space, the test fails.

  • Connection to NeoLoad Web. If the controller can't reach NeoLoad Web, it can't publish results.

Load generators

Monitor the following on each load generator:

  • Online status. Go to Infrastructure in NeoLoad Web and check that all load generators show as online.

  • CPU and memory use during test runs. A saturated load generator produces unreliable results because it can't simulate users accurately.

  • Network bandwidth. Load generators that generate heavy traffic can saturate the network link, which affects response time measurements.

NeoLoad Web, on-premise only

If you run NeoLoad Web on your own infrastructure, monitor the following:

  • Web server health. Confirm the NeoLoad Web interface loads correctly and responds quickly.

  • Database health. Check connection pool use, query response times, and disk space. A slow or full database affects every user.

  • Disk space for test result storage. Results accumulate over time. Monitor disk use and review retention policies before you run out of space.

Network

Verify the following network connections on a regular basis:

  • Can the controller reach all load generators?

  • Can load generators reach the application under test?

  • For cloud and hybrid deployments: outbound HTTPS to the Tricentis cloud.

Create backups and recover

A solid backup strategy protects you from data loss and speeds up recovery when something fails. What you include depends on your deployment model:

What to include in backups

Create backups of the following components:

  • Controller configuration: The controller stores license files, connection settings, and local test data. Create a backup before updates and on a regular schedule.

  • Load generator configuration: Each load generator stores its registration and connection settings. Save copies so you can restore them quickly after a failure.

  • NeoLoad Web database, on-premise only: This holds all test results, user data, workspace configuration, and project files. Create backups regularly. The frequency depends on how much data you can afford to lose.

  • Test projects: Store test projects in a version control system such as Git. This gives you version history and makes it easy to restore a project if something goes wrong.

Recovery approach

How you recover depends on your deployment model:

  • Cloud and hybrid: Tricentis manages the NeoLoad Web platform and its data. Your recovery responsibility is limited to the controller, on-premise load generators, and monitoring agents. Reinstall and restore the configuration from backups.

  • On-premise: You're responsible for the full stack. Plan for both partial failure, where a single component fails, and full disaster recovery, where the entire environment is lost. Test your recovery procedure at least once before you need it.

Manage test result storage

Test results accumulate over time, especially if you run tests frequently or store detailed transaction data. Left unchecked, this consumes disk space and slows the database.

To keep storage under control:

  • Review test results regularly and delete results you no longer need.

  • Configure retention policies in NeoLoad Web to automatically remove old results after a set period.

  • Archive important results before you delete them if you need to keep them for compliance or historical comparison.

  • For on-premise deployments, monitor database size and plan for storage growth based on your test frequency.

Update components

Tricentis releases updates for NeoLoad components regularly. Updates include new features, bug fixes, and security patches. Plan updates carefully to avoid disruptions.

Follow this order when you update:

  1. Review the release notes to understand what changed and whether the update affects your configuration.

  2. Create backups of all component configurations and the database. This applies to on-premise deployments.

  3. Schedule a maintenance window. Don't update while tests are running.

  4. Update the controller first.

  5. Update load generator agents.

  6. Update NeoLoad Web. This only applies to on-premise deployments. For cloud deployments, Tricentis does this automatically.

  7. Run a short test to verify everything works after the update.

Troubleshoot failures

When something goes wrong, use the following guidance to diagnose and resolve the issue:

Test fails to start

If a test won't start, check the following:

  • Check that load generators are online and available in the selected zone.

  • Verify that the controller can communicate with all load generators.

  • Confirm that your license has enough capacity for the number of virtual users in the test.

  • Check whether the scenario is valid and the project uploaded correctly.

Results don't appear in NeoLoad Web

If results are missing after a test run, check the following:

  • Verify that the controller can reach NeoLoad Web. Check the API token and network access.

  • Confirm you selected the correct workspace for the test results.

  • Check whether the storage quota is exceeded. For on-premise, check disk space. For cloud, check subscription limits.

Poor test performance or unexpected results

If response times are higher than expected or results look wrong, check the following:

  • Check load generator CPU and memory. If a load generator is saturated, it can't simulate users accurately, and the measured response times don't reflect the real application performance.

  • Check network bandwidth between load generators and the application.

  • Verify that the application under test has enough resources, specifically CPU, memory, and database connections, for the load you generate.

  • Review test data and correlation settings. Missing or incorrect correlation can cause request failures.

Users can't access NeoLoad Web

If users can't sign in or see the interface, check the following:

  • Check user accounts and permissions. Confirm the user is assigned to the correct workspace.

  • Verify that the NeoLoad Web service is running. This applies to on-premise deployments.

  • Check firewall rules and network access to the NeoLoad Web server.

  • If you use SSO, verify the SSO configuration.

What's next

For detailed setup procedures, see the following topics: