Configuration: Workloads
Overview
Use this page to upload and manage workload scripts (.lgs files). A workload is the sequence of actions, built in LoadGen Studio, that a virtual user or monitored session replays: the screens it opens, the steps it performs, and the wait events it pauses on. Without an uploaded workload, there is nothing for a load profile or monitoring profile to run, so this page is the catalogue every test and monitoring job depends on.
A workload arrives here as a finished .lgs file; this page manages the file, not its content. Once uploaded, Load Profiles consume it to generate load during a test run, and End-to-End Monitoring profiles consume it to replay the same actions as a synthetic check. The TESTING and MONITORING columns reflect that usage for each file.
From here you upload new workloads or new versions of an existing one, inspect a file's version history, download its current content, and delete workloads or folders you no longer need. You can also publish a workload to the LoadGen Exchange for others to import, or pull in updates to one you previously imported.
Key concepts
- workload - A .lgs script file, built in LoadGen Studio, that defines the actions a virtual user or a monitored session replays during a run. (related: Testing: Load Profiles)
- version tag - The version number shown next to a workload's name (for example v1.0, v1.8); it increases according to the Version Bump option chosen when the file is uploaded.
- Version Bump - An upload-time choice (No version change, Minor, Major, or Patch) that determines whether and how a workload's version tag changes when you upload new content.
- LoadGen Exchange - A shared catalogue you can publish a workload to, or pull workload updates from, instead of distributing .lgs files manually.
When to use it
- Before configuring a load profile that needs a new or updated workload script.
- When you need to check whether a workload is currently used by testing or monitoring.
- When you need to inspect or recover an earlier version of a script.
- When publishing a workload for other environments to import, or pulling in an update from the LoadGen Exchange.
- When cleaning up outdated or unused .lgs files and folders.
Before you begin
- Have a finished .lgs workload script ready, authored in LoadGen Studio; this page uploads and manages files but does not create or edit script content.
- Confirm your account role includes workload management grants, configured in Operations: Permissions; roles limited to read access only see Version history and Download workload, never upload or delete.
- If you plan to use Share with everyone…, sign in to your LoadGen Cloud account first.
Common workflows
Upload a new version of a workload script
Persona: Load test operator preparing a script update
- Click Upload new version (or Upload Workload) for the file you want to update.
- Expect: The upload dialog opens with Target Folder, Version Bump, and Commit Message fields.
- Select the updated .lgs file from your computer.
- Expect: Only .lgs files are accepted; anything else you select is skipped and listed in a message.
- Choose a Version Bump option and enter a Commit Message describing the change.
- Expect: The chosen option is highlighted and your message text appears in the field.
- Click Upload.
- Expect: An Upload Successful message appears, and the workload's row updates with its new version tag, size, and Modified timestamp.
Verify: The row for that workload shows the new version tag next to its name and a current Modified date; Version history lists the new version with the commit message you entered.
Review a workload's version history and download its current content
Persona: Admin auditing which script version is live
- Click the Version history icon on the workload's row.
- Expect: A panel opens listing the file's earlier saved versions by version tag and date.
- Click Download workload for that row.
- Expect: The file's current live content downloads to your computer.
Verify: You have a local copy of the exact content currently stored on the platform, and the history panel shows which version tag it corresponds to.
Steps
Step 1
Open the Workloads page.
Expected result: The page loads the workload table with NAME, PATH, SIZE, TESTING, MONITORING, MODIFIED, and ACTIONS columns, listing every uploaded .lgs file (4 files, 0 folders in this example), each row showing its current version tag next to the file name.
This table is the starting point for uploading, auditing versions, and managing every workload script used across Load Testing and End-to-End Monitoring.
- Upload Workload opens the upload dialog for new files or new versions.
- Refresh reloads the list without changing any file.
- Each row's version tag (for example v1.8) sits next to the file name.
- The TESTING column shows a numbered badge instead of a dash when the workload originated from a Functional Testing package.
-
MODIFIED and SIZE help you spot stale or oversized scripts at a glance.
Field reference
| Field | Purpose | Format / Validation | Required | Default |
|---|---|---|---|---|
| Target Folder (optional) | Sets which folder the uploaded file is placed in. Leave it empty to upload to the root of the workload list, or type a folder name to group related scripts together. | text | No | empty (root) |
| Version Bump (optional) | Controls whether and how the uploaded file's version tag changes. Choose No version change to upload without touching the version number, Minor for a small, backward-compatible script update, Major for a substantial rewrite, or Patch (overwrite current) to replace the current version's content without incrementing the tag at all. | radio selection: No version change / Minor / Major / Patch (overwrite current) | No | No version change |
| Commit Message | A free-text note describing what changed in this upload; it is attached to the version it creates and shown later in Version history. | text | No | empty |
Column reference
| Column | What it shows | How to read it |
|---|---|---|
| NAME | Identifies the workload file and shows its current version tag next to the name. | A higher version number means the file has been uploaded and bumped more times; check Version history to see what changed at each step. |
| PATH | Shows the file's location in the workload folder tree. | Matches NAME for a file stored at the root; a longer path means the file sits inside one or more folders. |
| SIZE | Shows the size of the .lgs file on disk. | Use it to spot unusually large scripts that may slow uploads or downloads. |
| TESTING | Shows whether the workload is currently linked to testing usage. | A dash means no recorded testing usage; a numbered badge means the workload was generated from a Functional Testing package, and clicking it opens that package when your role has access, or shows as plain text otherwise. |
| MONITORING | Shows whether the workload is currently linked to monitoring usage. | A dash means the workload is not currently referenced by any monitoring profile; a numbered badge, shown the same way as in TESTING, means it is in use. |
| MODIFIED | Shows the date and time the file was last uploaded or updated. | Use it to confirm a recent upload went through, or to find stale scripts nobody has touched recently. |
| ACTIONS | Holds the icon buttons available for that row. | Only the icons your role is permitted to use appear; a read-only role sees fewer icons than an administrator. |
Controls reference
Upload Workload
Opens a dialog to upload one or more new .lgs files, with Target Folder, Version Bump, and Commit Message fields.
When to use: Use it to add a new workload script, or additional files into a folder.
Side effects: Mutating: confirming the dialog adds new row(s) to the table and shows an Upload Successful message; any non-.lgs files you selected are skipped and named in a message.
Refresh
Reloads the workload list from the server.
When to use: Use it after uploading or deleting a file elsewhere, or when the list looks out of date.
Side effects: Read-only: reloads the table; makes no change to any file.
Upload new version
Opens the same upload dialog as Upload Workload, pre-targeted to update this specific file.
When to use: Use it when you have a new build of an existing workload and want to bump or overwrite its version rather than uploading an unrelated file.
Side effects: Mutating: confirming the dialog updates the file's version tag, size, and Modified date according to the Version Bump choice.
Version history
Opens a panel listing the workload's earlier saved versions.
When to use: Use it to check what changed between versions, or to find an older version before deciding whether to upload a new one.
Side effects: Read-only: viewing history does not change the current file.
Download workload
Downloads the file's current, live content to your computer.
When to use: Use it to inspect, back up, or hand off the exact script currently stored on the platform.
Side effects: Read-only: downloading does not alter the stored file; it always returns the current version, not a historical one.
Delete (workload)
Deletes a single workload file after a Delete Workload? confirmation.
When to use: Use it to remove a script that is no longer needed.
Side effects: Mutating and destructive: the file is permanently removed from the list; a failed or refused delete shows an error banner above the table that stays until you dismiss it.
Delete folder
Deletes an entire folder of workloads after a Delete Folder? confirmation.
When to use: Use it to remove a folder and everything in it once none of its contents are needed.
Side effects: Mutating and destructive: removes the folder and its files; not offered to roles without delete grants.
LoadGen Exchange menu
Opens a small menu of Exchange actions for that workload.
When to use: Use it when you want to publish, share, or update a workload through the LoadGen Exchange.
Side effects: Read-only itself, since it only opens the menu; the mutating effect happens once you pick a menu item.
Publish to the LoadGen Exchange…
Opens a dialog to publish this workload to the Exchange.
When to use: Use it to make a workload available for other environments or users to import.
Side effects: Mutating: publishing makes a version of the workload available through the Exchange.
Share with everyone…
Asks Share with everyone? and then shares an item you previously imported with every user.
When to use: Use it for a workload you imported from the Exchange yourself and now want visible to everyone.
Side effects: Mutating: requires you to be signed in to your LoadGen Cloud account; if you are not, the action fails with a message pointing you to the Account page.
Update to (version)
Updates an imported workload to a newer version published since it was imported.
When to use: Use it when a newer version of a workload you imported from the Exchange becomes available.
Side effects: Mutating: replaces the local file's content and version tag with the newer imported version.
Run as functional test
Re-runs a workload that was generated from a Functional Testing package, as a functional test.
When to use: Only relevant for a workload carrying a TESTING usage badge that originated from a Functional Testing package.
Side effects: Shown disabled from this page: running it needs the Suite engine, which this page does not provide; offered only to roles whose grants open Functional Testing packages and runs.
Verify the result
After a successful upload, the workload's row shows the file name with its updated version tag, the new file size, and a Modified timestamp matching the time of upload, and an Upload Successful message confirms the action. If you set a Version Bump, the tag next to the name changes accordingly, for example v1.0 to v1.1 for Minor, while Patch (overwrite current) leaves the tag unchanged but replaces the content. If the row still shows the old version tag or Modified date after uploading, click Refresh to confirm the change registered before assuming the upload failed. The TESTING and MONITORING columns continue to reflect any existing usage links, which an upload does not remove.
Troubleshooting
- Symptom: The Upload Workload button or a row's Delete and Upload new version icons are missing. Fix: Check your role's grants in Operations: Permissions; a read-only role is offered only Version history and Download workload, never upload or delete.
- Symptom: A file you selected in the upload dialog never appears in the list. Fix: Only .lgs workload scripts can be uploaded here; any other file type is skipped, and the skipped file names are listed in the confirmation message.
- Symptom: After attempting a delete, the table disappears and only a banner shows. Fix: Read the banner above where the table was; it reports why the delete was refused or failed, for example the workload is still referenced elsewhere, and it stays on screen until you dismiss it.
- Symptom: Run as functional test is visible but greyed out. Fix: This control only applies to a workload generated from a Functional Testing package; running it again needs the Suite engine, which this page does not provide, so it stays disabled here.
- Symptom: Share with everyone… fails immediately. Fix: Sharing uses your own LoadGen Cloud account; sign in on the Account page under LoadGen Cloud, then retry the share.
- Symptom: Download workload returns an error. Fix: Check the reported error message and retry; download always fetches the current live content, so a workload deleted or renamed elsewhere will fail until you refresh the list.
Related articles
- Next step: Testing: Load Profiles - Load Profiles reference an uploaded workload script when configuring what a virtual user runs.
- Next step: End-to-End Monitoring: Profiles - Monitoring profiles can replay the same workload scripts as a synthetic check.
- See also: Configuration: Testing: Scenarios - Scenarios combine an uploaded workload with other test settings before it runs.
- Prerequisite: Operations: Permissions - Upload and delete actions on this page require workload management grants configured for your role.