Troubleshoot and Debug with UP9

After a one-time install, UP9 begins monitoring traffic in your system, discovering service architecture and business logic, and building machine-generated tests. UP9's service map, machine-generated tests, and mocks are built from this monitored traffic.

Once you have installed and deployed UP9, generate traffic so UP9 can build skeleton test code. The more traffic, the more reliable and CI-ready the test code becomes.

View Test Code

View the CI-ready test code that is automatically created. The test code provides full coverage of the business logic, and includes a sequence of API calls, traversing the business logic graph satisfying dependencies and asserting results. It includes service endpoint calls, data extraction, and assertions.


Run Test Code

Terminal Testing

Use this command to test from the Terminal window:

Copy to clipboard
|up9 test:run-local all

The 'run-local' option will cause the test to run from where you installed the UP9 CLI. If the UP9 CLI is installed on your laptop, it will run from your laptop.

Once the test run is complete, test results are available in the Workspace Summary tab in the UP9 browser.

Cloud Testing

UP9 can also test with a cloud runner. This method only works when the web app being tested is publicly available. If the webapp is local, please use the local method detailed above.

On UP9's Tests page, select a test collection and choose Run Now.


When the test is finished, UP9 will generate a report.

View Test Reports

Your test reports reliability and coverage of services, and it can go even deeper than that.

The Reliability Score is a success ratio of the recent test Service Endpoint calls. The Reliability Score histogram is available for each test execution, so you can view and compare old test results with new test results. If you see a low reliability score, it means that UP9 wasn't able to learn your architecture from the first testing pass, and needs more information.

The Coverage Score represents the ratio of active to inactive test-spans.


You can also view the actual response from the service for troubleshooting.


Root Cause Analysis

To address specific failures and see what caused them, you can take a deeper look:


You can see that a certain failure was caused by an assertion where the response code was expected to be 201 and it was 200. You can dig deeper into the HAR payload to see exactly what happened:



For support, feel free to use any one of the three: