# Configure traffic and test settings

Traffic settings control how many sessions start, when they start and where they run. Choose a traffic shape and estimate usage before a run.

## Before configuring load {#before}

A load test needs a [validated scenario](https://userlimit.com/documentation/journeys/validate.md) and a verified target you have permission to test. The [sessions and concurrency](https://userlimit.com/documentation/concepts/sessions-and-concurrency.md) guide explains the workload settings, while [usage and billing](https://userlimit.com/documentation/reference/usage-and-billing.md) explains how session duration affects cost.

## Test settings {#controls}

| Control | Accepted values and behavior | Initial setting |
| --- | --- | --- |
| Scenarios | At least one. A single scenario gets all the traffic; with several, their Traffic percentages must total 100%. Shares allocate starts, not active browsers. | When opened from a scenario, that scenario receives 100%. |
| Number of sessions | Positive whole number; capacity depends on the account limit, traffic pattern and scenario time limits. | Up to 200, reduced to the account limit when lower. |
| Arrival window | 10 seconds to 1 hour, picked on a slider. Sessions start during this window; the run lasts longer while the last ones finish. | 90 seconds. |
| Traffic pattern | Constant load, Rising load, Early spike, Random or Custom. | Constant load. |
| Custom traffic pattern | 24 relative arrival weights from 0 to 100, with at least one positive weight. | Defined by your selected points. |
| Locations | Pick locations allows a selection from the available locations. Each session is assigned to one of the selected locations at random. | All available locations; the button shows the current number of locations. |
| Error threshold | Greater than 0 and at most 100 percent. Stops after the failed-session rate exceeds it, once at least 10 sessions have outcomes. | 5%. |
| Schedule | Daily, weekly or monthly recurrence; review and disable if a one-off test is intended. | The new-test form is prefilled with a weekly schedule. |

## Choose a traffic shape {#profiles}

**Constant load** spreads session starts approximately evenly across the arrival window, while **Rising load** places more starts later in the run and **Early spike** concentrates them near the beginning before declining. **Random** varies the relative arrival weights, and **Custom** uses your 24 points to define the shape.

Each pattern describes requested session starts rather than a target number of concurrent users. The number active at any moment also depends on how long the sessions take to complete.

## Estimate usage and concurrent users {#estimate}

Under the load settings, a chart draws the session starts over the arrival window and the time the last sessions can still run, with the run length (up to the window plus the longest scenario time limit) and the estimated usage. It updates as you change the settings. When creating a test, scenarios are picked after the load, so the run length and usage show on the scenario step. If the settings need more concurrent users than your limit, the form says so and offers the largest number of sessions that fits.

For a fictional 600-session run over ten minutes, the average arrival rate is one start per second. At 20–45 seconds per session, total usage is roughly 3.33–7.5 VUh. The website slowing down can increase both usage and concurrent users.

If half the starts follow a 10-second scenario and half a 50-second scenario, usage is (300 × 10 + 300 × 50) / 3,600 = 5 VUh. In a stable one-start-per-second period, the scenarios contribute about 5 and 25 active sessions respectively.

## Before starting a run {#review}

The selected scenarios and traffic settings define the workload that will be requested, so they need to match the intended test and the permission granted for its environment. Validation helps confirm that the scenarios can execute, while the [production safety guide](https://userlimit.com/documentation/help/production-safety.md) covers side effects and monitoring for live sites.

The usage estimate and available hours help with planning, but the estimate is not a spending cap. Schedule and notification settings determine whether it will recur and how results will be delivered; someone should remain available to monitor the site and stop the run if needed.

If the workload exceeds available capacity, fewer sessions or a longer arrival window may allow it to fit within the account limit. Support can confirm a higher limit before usage is purchased. The [troubleshooting guide](https://userlimit.com/documentation/help/troubleshooting.md) covers other reasons a run may not start.

## Related guide {#next-step}

[Start, stop and monitor a run](https://userlimit.com/documentation/runs/lifecycle.md)