Configuration: Workloads
Overview
Use this page to upload and manage workload scripts (.lgs files). A workload is the file LoadGen Studio produces to define what a simulated user or transaction does during a run; tests and monitoring checks execute it instead of redefining that behavior each time. Keeping workloads in one shared library lets every test or monitor reuse the same script instead of re-uploading duplicate copies.
A workload typically starts in LoadGen Studio, where you record the session, then is uploaded here before a test or monitor can use it. Once uploaded, it's selected from Testing: Load Profiles to run as a load test, or from an End-to-End Monitoring profile to run as a recurring check. The TESTING and MONITORING columns here show how many of each depend on it.
On this page you can see every uploaded workload with its size, usage counts, and last-modified time; upload a new file or a new version of an existing one with an optional target folder and version bump; review a file's version history; download its current content; and delete files no longer referenced anywhere.
Key concepts
- workload - A .lgs script file produced by LoadGen Studio that defines the actions a simulated user or transaction performs during a run. (related: Testing: Load Profiles)
- Version Bump - A choice you make when uploading a replacement file: Minor or Major adds a new, incremented version while keeping the prior one; Patch (overwrite current) replaces the current version's content without adding a new version entry.
- TESTING / MONITORING usage count - A numbered chip in the TESTING or MONITORING column that shows how many load-test or monitoring configurations currently reference this workload; a dash means none do. (related: End-to-End Monitoring: Profiles)
- Credential Profile - A stored set of credentials used to authenticate calls from a test or monitoring configuration; the banner on this page can warn you when one tied to your workloads is close to expiring. (related: Configuration: Credential Profiles)
When to use it
- You have a new workload script exported from LoadGen Studio and need to add it to the shared library before running a test.
- An existing workload needs updating, and you want to check its TESTING/MONITORING usage count before overwriting it.
- You're cleaning up unused assets and need to confirm a workload has no references (dash in both usage columns) before deleting it.
- You need to download the current content of a shared workload to edit it in LoadGen Studio.
- You need to review a file's version history to find out what changed or to recover an older version.
- You see a credentials-expiring notice referencing a token your test or monitoring workloads depend on.
Before you begin
- You have a .lgs workload file ready to upload, produced by LoadGen Studio.
- Your account role has upload/delete permissions for Workloads; read-only roles are not offered the Upload Workload or Delete workload controls.
- If a credentials-expiring notice points to a token used by your workloads, the replacement credential has already been reissued under Configuration: Credential Profiles.
Common workflows
Upload a new workload script
Persona: Load-test operator
- Select Upload Workload in the page header.
- Expect: The Upload modal opens with fields for a file, Target Folder, Version Bump, and Commit Message.
- Choose the .lgs file to upload and, optionally, enter a Target Folder.
- Expect: The file is staged for upload; leaving the folder blank keeps it at the library root.
- If replacing an existing workload, select a Version Bump option and add a Commit Message describing the change.
- Expect: Your version choice and note are attached to this upload.
- Select Upload.
- Expect: The button changes to Uploading..., then the modal closes and the workload appears (or updates) in the table with a new SIZE and MODIFIED timestamp.
Verify: The workload appears in the table with the expected version badge and an updated MODIFIED timestamp; if you replaced an existing file, its version advanced according to the bump you chose.
Retire an unused workload
Persona: Admin
- Check the TESTING and MONITORING columns for the workload you plan to remove.
- Expect: Both columns show a dash, confirming no test or monitoring configuration currently references the file.
- Select Delete workload in that row.
- Expect: A confirmation dialog titled Delete Workload? opens.
- Confirm the deletion.
- Expect: The row disappears from the table and the file count in the summary line below the table decreases by one.
Verify: The workload no longer appears in the list, and the '0 folder(s), N file(s)' summary reflects the lower file count.
Steps
Step 1
Open the Workloads page.
Expected result: The table lists the uploaded workload scripts, here 4 files and 0 folders, with each row's NAME, PATH, SIZE, TESTING/MONITORING usage, and MODIFIED date; a Credentials expiring banner appears in the top-right corner warning that an Orders API token expires soon.
This is the library you work from before uploading, versioning, or removing any workload script.
- The Credentials expiring banner includes a Dismiss control to close it.
- Office Worker.lgs shows a usage chip (1) in TESTING, meaning a test configuration already references it; the other files show a dash in both usage columns.
Step 2
Select Refresh.
Expected result: The list reloads; the Credentials expiring banner clears, and the Upload Workload and Refresh controls become visible at the top of the page.
Refreshing confirms the table is current and clears the way to the Upload Workload control before you add or change a file.
- Upload Workload opens the modal for adding a new file or a new version.
-
Refresh re-queries the list without navigating away from the page.
Field reference
| Field | Purpose | Format / Validation | Required | Default |
|---|---|---|---|---|
| Target Folder (optional) | Chooses the folder the uploaded file is placed under. Leave it blank to upload to the library root; set it to group related scripts (for example by project) so usage is easier to scan across TESTING/MONITORING. | text | No | (root) |
| Version Bump (optional) | Controls how the upload affects versioning. No version change uploads as a fresh file; Minor or Major increments the version number and keeps the prior version's history, with Major reserved for bigger changes; Patch (overwrite current) replaces the current version's content without adding a new version entry, so choose it for small fixes you don't need to retain history for. | single-select: No version change, Minor, Major, Patch (overwrite current) | No | No version change |
| Commit Message | A free-text note describing what changed in this upload, useful to anyone reviewing Version history later. | text | - | - |
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. | The version badge (for example v1.0) shows the version currently in use; it only changes when you upload a replacement with a Minor or Major version bump. |
| PATH | Shows where the file sits within the workload folder structure. | Until you organize files into folders, PATH repeats the file name because every workload sits at the library root. |
| SIZE | Shows the uploaded file's size, useful for spotting an unexpectedly small or empty script export. | An unusually small size compared to similar scripts can indicate a corrupted or incomplete export from LoadGen Studio. |
| TESTING | Shows how many load-test configurations reference this workload, so you know whether it's safe to overwrite or delete. | A dash means no test configuration uses this file yet; a numbered chip (for example 1) shows how many do. |
| MONITORING | Shows how many End-to-End Monitoring profiles reference this workload, so you know whether it's safe to overwrite or delete. | A dash means no monitoring profile uses this file yet; a numbered chip would show how many do. |
| MODIFIED | Shows when the file's content was last changed, so you can confirm a recent upload actually took effect. | This timestamp updates whenever a new version or overwrite is uploaded, not when the row is merely viewed. |
| ACTIONS | Houses the per-row controls available for this workload. | Which icons are enabled depends on your permissions; a read-only role sees fewer or none. |
Controls reference
Upload Workload
Opens a modal to upload one or more .lgs files into the library, with optional Target Folder, Version Bump, and Commit Message settings.
When to use: When you have a new or updated workload script from LoadGen Studio to add to the shared library.
Side effects: Mutating: once submitted, creates a new workload entry or a new version of an existing one; the table refreshes to show it.
Refresh
Reloads the current list of workload files without navigating away from the page.
When to use: After uploading or deleting files elsewhere, or to confirm the table reflects the latest state.
Side effects: Read-only: no workload data changes, though the page re-queries its state and time-sensitive banners (like a credentials-expiring notice) can clear as a result.
Version history
Opens a view listing prior versions of that workload file.
When to use: Before overwriting a workload, to see what changed previously, or to identify an older version you need to recover.
Side effects: Read-only: opens a view only, nothing on the workload changes.
Download workload
Downloads the current (live) content of the .lgs file to your machine.
When to use: To inspect or edit the script in LoadGen Studio before re-uploading it as a new version.
Side effects: Read-only: no changes to the workload record.
Delete workload
Opens a confirmation prompt (Delete Workload?), then permanently removes the workload file and its version history.
When to use: When a script is no longer used by any test or monitoring configuration, shown by a dash in both TESTING and MONITORING.
Side effects: Mutating and destructive: the file and all of its versions are removed from the library; this control isn't offered at all to a role whose permissions refuse the delete.
Upload new version
Opens the Upload modal pre-targeted at that specific file, for attaching a new version instead of adding a separate file.
When to use: When you have an updated version of an existing script and want to keep its usage links and version history intact.
Side effects: Mutating only once you complete the upload inside the modal; opening it alone changes nothing.
Dismiss
Closes the credentials-expiring notice banner.
When to use: Once you've noted the warning or already handled it under Configuration: Credential Profiles.
Side effects: Cosmetic only: hides the banner for this session; it does not renew or affect the underlying credential.
Close
Closes the Upload modal without uploading anything.
When to use: When you opened the modal by mistake or decide not to upload.
Side effects: Read-only: discards any file selection made in the modal; no workload changes.
Cancel
Closes the Upload modal without uploading, from the modal's action row.
When to use: After reviewing the selected file and settings, if you decide not to proceed.
Side effects: Read-only: discards the pending upload; no workload changes.
Upload (modal button)
Starts uploading the selected file using the chosen Target Folder, Version Bump, and Commit Message; shows Uploading... while in progress.
When to use: After selecting a file and setting any folder/version options you need.
Side effects: Mutating: creates or updates the workload entry; the table reflects the new or updated row once the upload completes.
Verify the result
After an upload, the affected row shows its new version badge, updated SIZE, and a refreshed MODIFIED timestamp; after a delete, the row is gone and the '0 folder(s), N file(s)' summary count drops by one. The TESTING and MONITORING columns tell you at a glance whether a file is safe to change: a numbered chip means a test or monitoring configuration depends on it, a dash means none does. If nothing changed after an upload, select Refresh to rule out a stale view. If Upload Workload or Delete workload are missing from the page, your account role likely has read-only access to Workloads.
Troubleshooting
- Symptom: The Upload Workload and Delete workload controls are missing from the page. Fix: Your account role only has read access to Workloads; ask an administrator to grant upload/delete permissions for this module.
- Symptom: An uploaded file doesn't appear in the list. Fix: Confirm the file has a .lgs extension; files without it are skipped during upload and listed in a message above the table.
- Symptom: You can't tell whether it's safe to delete a workload. Fix: Check the TESTING and MONITORING columns; remove the file's references from any listed test or monitoring configuration first.
- Symptom: Download or delete fails with an error banner. Fix: Retry the action; if it persists, confirm the file wasn't already removed by another operator or that your connection to the API is stable.
- Symptom: The credentials-expiring notice keeps reappearing. Fix: Reissue the referenced credential under Configuration: Credential Profiles; selecting Dismiss only hides the banner for this session.
- Symptom: The table shows 'No workloads found'. Fix: No .lgs file has been uploaded yet in this environment; select Upload Workload to add the first one.
Related articles
- Next step: Testing: Load Profiles - A load profile selects an uploaded workload to run as a test.
- Next step: End-to-End Monitoring: Profiles - A monitoring profile references an uploaded workload to run as a recurring check.
- See also: Configuration: Credential Profiles - Reissuing an expiring credential referenced by a workload's test or monitoring configuration happens there.