Guía de usuario

2. Getting started

k6 on your machine

• Windows (usual installer): the app usually ships with k6 ready to use; you do not need to install it separately to run tests from Performate.
• macOS and Linux: coming soon.
• If you have Pro or higher, you can also build custom k6 binaries (with extensions) from the xk6 builder; see Section 12 — Tools.

Account and first use

• Sign in: enter email and password or the method shown on screen (sometimes also Google).
• First time: a Default Workspace is created with no folders or tests; changes save automatically as you work.
• After login you may see a welcome tour (onboarding) that highlights the main areas of the UI; you can skip it and pick it up later if the app offers that.

---

3. Workspaces and organization

Workspace tree

• Workspaces: group your tests; you can have several.
• Folders: inside a workspace, organize tests into folders.
• Sidebar: you can resize it; double-click the separator to collapse or expand it.
• Workspace row (workspace name): clicking it focuses the root of the tree (imports and the “no folder” bucket in the workspace context). If you select a folder or request in the tree, the root highlight yields to the selected item so it does not look like two places are active at once.
• Multi-select: choose several requests and/or saved examples under a request with Ctrl (Windows/Linux) or Cmd (macOS) while clicking, or extend the selection with Shift + arrows in the tree. Useful for bulk delete or duplicate and to run several tests in parallel (see Parallel execution).
• File → Save / Save all: force-save tabs or the full dataset when you need it (in addition to autosave).

Standalone k6 scripts (.js / .mjs file in the workspace)

• If you drag and drop into the window a file that is a valid k6 script (and you do not mix forbidden types with other files in the same drop), the app imports it as an independent saved script (orphan), at the workspace root, without creating a folder named after the file.
• The destination of a global drop is always the workspace root (not the folder of the request you have selected in the tree). To choose a specific folder when importing several scripts from the wizard, use the import API modal and the folder you pick there or in the tree.
• In the sidebar, with the workspace expanded, those scripts appear below the “JS library” block and above the workspace folders: same idea as a saved example under a request (flask icon), but they live at the tree root until you move them into a folder from the app.
• If you delete the workspace, those root scripts are removed with it (and their tabs close if they were open).

Workspace JS library (code shared across your tests)

What is it?

It is a drawer of JavaScript files belonging to that workspace: use it to store code snippets that several requests or k6 scripts can use without copy-pasting the same text everywhere.
It does not replace the main test script: it is supporting material (for example a function that builds headers, a map of test URLs, repeated validations, etc.).

Where do I see it?

With the workspace expanded in the sidebar, under the name you will see the JS library block (or the equivalent name if you change the UI language). There you list folders and files that exist only in that workspace and that you manage from the app itself (create, edit, move, delete).

What you can do (step by step)

1. Create folders or files with the block header buttons, or with right-click on the root or a folder. New files must use the .js or .mjs extension.
2. Bring files from your PC: drag .js / .mjs onto the library block. If the file looks like a complete k6 script (a ready-to-run test), the app may reject it here on purpose: that kind of file belongs in import or the test script, not in the helper library.
3. Open and edit: click (or double-click) a file opens a tab with the editor. Save with Ctrl+S when there are changes, same as other tabs.
4. Reorder: drag rows to move files or folders. You can select several with Ctrl/Cmd + click or a range with Shift + arrows when focus is in the library. Delete or Backspace with a selection may ask you to confirm deletion.
5. Copy and paste inside the library: with nodes selected, Ctrl+C and Ctrl+V duplicate or move parts of the tree into the destination folder you have active (if you only select a file, the paste destination is usually its containing folder). You can also drag files from the desktop onto the block.
6. Context menu (right-click): besides create, rename, or delete, you will see copy import path: that is the line you paste into your k6 script to link that file (shaped like ./something.js or ./folder/something.js).

How to use it from your k6 script

In the request script editor (or in a saved example), write a relative import using exactly the path from copy import path, for example:

import { miFuncion } from './helpers/login.js';

When you run the test from Performate, the app ships the main script together with the library files needed for those paths (and files they import in turn). You do not upload them elsewhere: they live inside the same workspace you already save with the app.

If you run outside the app (CI, terminal, another machine)

From Performate everything stays linked. If later you use only an exported script or tools like npx performate run, you may receive a single generated file: in that case library files do not “travel on their own”; you will need to copy them into your project or follow the options the Automation Hub (Pro+) indicates so the CI environment has the same file structure.

Note for advanced users

Library data is stored with the workspace (including in the workspaces JSON the app keeps per profile). In the context menu of the library header you can open the workspace folder in the file explorer if you need to locate that file on disk.

Datasets (per-profile CSV data)

In the lower area of the side panel you will see Datasets, separate from the folders/tests tree. There you see CSV files and subfolders that live on disk, tied to your account / data profile (the same user folder under which your workspaces live): they are not duplicated per workspace in the list.

• The usual path on Windows looks like …\AppData\Roaming\Performate\data\<profile>\datasets\ (see also Data on your machine).
• Header — quick actions: new folder, new CSV, open datasets folder in the system explorer, and refresh the list from disk.
• Open CSV: clicking a file opens a center tab with a CSV text editor. With a CSV open, the top bar switches to data mode: it does not show HTTP controls or Run (it is not an executable k6 request until you open(...) from a script).
• Multi-select, move, rename, and delete: same as the rest of the tree (drag, context menu, Delete). To confirm a deletion, the app may ask you to type exactly the indicated string.
• Copy absolute path: context menu → Copy path. Useful for open('…') in setup(), the main script, or a saved example. An absolute path to the file under your datasets folder is usually the most stable when running from Performate.

Datasets vs data_files snippets

These are different paths. For data you manage in Datasets, use Copy path or write the correct path to your .csv.

Import and export (hub)

From the File → Import/Export menu (or the equivalent File menu entry) you open the hub that concentrates the usual paths:

Import

• Postman collection (JSON).
• cURL / API (cURL, gRPCurl, URLs, or Performate/Postman JSON per the wizard).
• k6 scripts (.js / .mjs).
• Workspace or environment as JSON.
• Dataset CSV file.
• Restore a full backup.

Export / backup

• Export workspace or environment.
• Full backup of the profile (workspaces, variables, examples, datasets depending on what the flow includes).
• You can also export / import standalone workspaces as JSON by dragging or from tree actions.

Postman and cURL import nuances

• Postman collection: a workspace is created with one request per item (Postman examples are not imported). If names repeat, they are renamed copy, copy 2, etc. Requests meant only for the app’s AI assistant are not imported.
• cURL / API: paste the command or URL as the on-screen wizard indicates.

Team workspaces (Pro+)

With a Pro+ plan you can share work with teammates:

1. In the sidebar, switch mode with the My workspaces | Team toggle.
2. In My workspaces, use Share with team on the workspace (or the equivalent context-menu action).
3. In Team mode you will see lists like Shared by me and Shared with me, the tree of shared items, and member management.
4. Invite by email and set independent permissions:
   • View — see shared requests and examples.
   • Run — launch tests (does not imply edit).
   • Edit — modify the shared copies (does not imply run). There must be at least one permission active per member.
5. Only active Pro+ accounts can share and receive invitations. If the owner is no longer Pro+, the team workspace stops being accessible for everyone; if a guest drops plan, they lose access.

Storage quota (Pro+): the owner has a combined quota (on the order of ~90 MB): local profile data plus team items they have shared. If sharing would exceed the limit, the app blocks the action and shows the storage notice.

Technical detail: Team workspaces docs in the app repository.

---

4. Test builder

Each request is defined in the center of the app: method and URL, query params, body (when applicable), headers, and validations. Values can include {{variableName}}, which are replaced by the active environment when generating or running the script.

HTTP method and URL

• Available methods: GET, POST, PUT, PATCH, and DELETE. You choose the method in the dropdown next to the URL bar.
• URL: enter the full endpoint address (for example https://api.example.com/v1/resource). It also accepts {{...}} variables in the URL.
• Although query params are often associated with GET, the Params table adds key–value pairs to the query string per the request configuration; you choose the method according to what the API requires.

Params (query parameters)

• Table of key, value, and notes (free text for documentation).
• Each row can be enabled or disabled without deleting it.
• Values can include {{variable}}. What you type here is concatenated onto the URL as a query string (for example ?page=1&limit=10).

Body (request body)

Body type is chosen in a dropdown. Options:

“raw” subtypes

If you choose raw, you can set the content format for highlighting and editor behavior:

• JSON — objects and arrays; the app can format (pretty-print) JSON when you ask.
• Text — plain text without JSON structure.
• XML — XML documents.
• HTML — HTML markup.

In the body editor you can also use {{variable}} inside the text when appropriate.

Headers

• Header table with name, value, and a checkbox to enable or disable each row.
• You can use {{variable}} in values (for example Bearer {{token}}).
• The app may suggest common values (content types or frequent headers) to go faster.
• Headers you set here are what k6 will send with the request (along with those the runtime adds based on body type).

Validations / Validations tab

On that tab there are two blocks (in this order in the UI):

1. k6 thresholds — rules on aggregated run metrics (e.g. http_req_duration with p(95), http_req_failed with rate). Each row has metric, optional tags (e.g. method:GET), statistic (p(95), avg, rate, etc.; on gauge-like metrics such as vus only value applies), operator (<, >, <=, >=), and numeric value. They are written into options.thresholds of the generated script; if a threshold is not met, k6 marks the run as failed (non-zero exit code). They act as a quality gate and are the usual requirement to generate full commands in the Automation Hub (see Section 12 — Tools).

2. Response checks — the validations described in the next subsection (check per request).

Validations / checks (assertions)

Validations are checks on the response. If any fails, the test is considered failed at the k6 level (check). You can have several rows and disable ones you do not want without deleting them.

Validation types:

1. Status code
   Checks the HTTP response status code. Operators:

   • equals — a specific code (e.g. 200).
   • in — comma-separated list of allowed codes (e.g. 200,201).
   • range — range (e.g. 200-299).

2. Response body
   Inspects the body as text. Operators:

   • contains — must contain a text fragment.
   • equals — exact match with the body (stricter use).
   • regex — must match a regular expression.

3. JSONPath
   On JSON responses, points to a value with a JSONPath expression (e.g. $.data.id). Operators:

   • exists — the node must exist.
   • equals — the value at that path must equal the expected one.
   • greater_than — numeric “greater than” comparison at that path.

4. Header (response header)
   You set the response header name and the expected value (for example checking Content-Type or custom headers).

5. Response time
   Checks the request duration in milliseconds. Operators: less than, greater than, or equal to the threshold you define.

---

5. Load types and models

On each test you configure which scenario you want to simulate (test type) and, except for monitoring, how you want to express load (model: virtual users or requests per second). The profile chart shows the shape of load over time; the k6 options preview translates that into what k6 will run.

Ways to model load (VU and RPS)

Available on all test types except Monitoring (this selector does not apply in monitoring).

• Virtual Users (VU)

  • You simulate how many concurrent users hit the system at once.
  • It is the natural way to think about “50 users on the web” or “200 open sessions”.
  • The app generates a profile where you ramp up, hold, or ramp down the number of VUs in phases (ramp-up, plateau, ramp-down, etc., depending on the test type).

• Requests per Second (RPS)

  • You set a throughput target: how many requests per second should be attempted overall (not how many users are behind it).
  • Useful when you care more about traffic volume than human parallelism (APIs, microservices, queues).
  • k6 distributes arrivals to approach that rate; in Performate, in RPS mode, the app may ask for an estimated average response time (in milliseconds) on some types, because it helps schedule the target rate.

How to choose: use VU if you think in terms of real user concurrency; use RPS if you have a throughput goal (“must sustain X requests per second”) or want to compare scenarios at a fixed rate.

---

Load

• What it is for: reproduce an expected “normal” or baseline load: stable traffic for a while, without seeking the system’s limit.
• Idea: you ramp from an initial level to a target (VU or RPS), hold it for a while, then ramp down in a controlled way.
• When to use it: validate that the service meets typical usage, before more aggressive tests, or as a baseline to compare versions.

Stress

• What it is for: increase load progressively up to a high peak and hold it, to see how the system behaves under sustained pressure.
• Idea: ramp up → plateau at the configured maximum → ramp down.
• When to use it: check degradation, queues, timeouts, or errors when traffic exceeds the usual but in a gradual way, not in a single hit.

Spike

• What it is for: simulate sudden traffic spikes: suddenly much more load, then back to calm (and you can repeat several spikes).
• Idea: start from a baseline, ramp quickly to a spike, hold it a while, recover to the base; the number of spikes is configurable.
• When to use it: launches, campaigns, viral news, event finales, or any case where traffic does not rise slowly but in jumps.

Endurance (soak)

• What it is for: leave the system a long time under moderate, stable load to detect memory leaks, slow degradation, errors that only appear after hours, or cumulative issues (disks, logs).
• Idea: controlled ramp-up → long stretch at sustained load → ramp-down.
• When to use it: when you need confidence in stability over time, not only in a short spike, before trusting prolonged production use.

Breakpoint

• What it is for: increase load in steps (more VUs or more RPS at each step) until you approach the point where the system stops meeting targets (errors, unacceptable latency, or saturation).
• Idea: at each step you hold the load for a fixed time, then raise another step, up to a maximum you define.
• When to use it: estimate the capacity ceiling, size infrastructure, or compare optimizations across versions.

Monitoring

• What it is for: periodically check that an endpoint responds (availability, smoke checks), not to generate massive stress load.
• Idea: you define an interval between requests and a total duration; the test runs repeated calls at that pace.
• In Performate: this type does not use the VU/RPS selector; monitoring runs do not open the embedded k6 dashboard like other tests, which fits a lighter use case.

---

Quick summary

---

6. Environments, variables, Setup Scripts, and k6 view

Environments (Postman style)

• Choose the active environment in the dropdown; you can create (+), rename, delete, and export.
• Environment names have a maximum of 15 characters (same as folders and tests in the app).

Variables

• In each environment you can define text, number, yes/no, and JSON variables.
• Use them in requests as {{name}}.

Import Postman environment

• Drag a Postman environment JSON to create a new environment, or use the File → Import/Export hub.

Setup Scripts (Setup tab)

In the test’s Setup tab (which may show as “Setup” / configuration script in the UI) you gather everything that happens once before the k6 scenario runs, plus options that change how the request is logged or which cookies are sent.

k6 setup() editor

• It is a code editor (k6-style JavaScript) dedicated to the setup() function: k6 runs it once at the start; whatever you return (return { ... }) is available to VUs as context data (tokens, IDs, prepared headers, etc.).
• Snippets menu with templates grouped by category. Choosing one inserts the code at the cursor (or at the end of the script). If the fragment brings imports that already exist in your script, the app avoids duplicating them.
  • Typical categories: Authentication (Bearer token, OAuth2 client credentials, Basic Auth), Data (random data, CSV loading with SharedArray, fetch IDs from an API), Setup Utilities (create test user, seed data, validate __ENV environment variables and return ready URLs or headers).
• Clear: empties the setup() editor completely.
• The editor has line numbers, highlighting, and folding for long scripts.

Automatic logging helpers

• A block titled in the app as help to choose what is written to the console during the generated script’s run (request/response).
• Request: checkboxes to log URL, method, body, and headers of the request.
  • The request Body checkbox is not available if the test method is GET (it does not make sense in that case).
• Response: checkboxes for status code, body, headers, and cookies of the response.
• Useful to debug without hand-editing the k6 script; keep in mind that logging full bodies can flood the console or expose sensitive data in shared environments.

Request cookies

• Table to define cookies k6 will send with the test request, using k6’s cookie jar (http.cookieJar() in the generated script).
• For each cookie you can set:
  • Name / Value
  • Path (e.g. /)
  • Domain (e.g. api.example.com)
  • Secure — send only over HTTPS
  • Max age — lifetime in seconds
  • Expires — expiry date (text the runtime accepts, e.g. 2026-12-31)
  • HttpOnly — cookie not accessible from browser JavaScript (relevant depending on how the client is simulated)
• Button to add rows and remove cookies you do not need.

k6 script preview

Another test tab (e.g. Preview / k6 script view), distinct from Setup:

• You see the generated k6 script from the builder (URL, method, body, headers, validations, load type, setup(), cookies, logging).
• Edit Script: switches to custom script mode: you stop relying on the generator for that test and edit the full text of the script. The app shows a notice that you are in custom mode.
• Discard: returns to the automatically generated script and loses manual changes from that mode.
• Save as Test: saves the current content as a reusable example tied to that request (see the next subsection).
• Copy the script to the clipboard and autocomplete in the editor (typical k6 API such as http.get, check, etc.) when editing by hand.
• From this view (and from a saved example) you can open the AI assistant for k6 scripts; see Section 8.

Saved examples (Save as Test)

Saved examples (also called test examples) are versions of the scenario tied to a parent request:

1. Open the request and go to the script preview (or edit the custom script).
2. Press Save as Test and give it a name.
3. In the tree, the example appears under the request (flask icon / similar).
4. You can run the example alone (uses its script and, depending on configuration, the saved load type) or select several examples and/or requests for parallel execution.
5. Rename, duplicate, or delete from the tree or context menu, same as other rows.

That way you keep variations (script A vs B, different load) without cloning the full HTTP request into another folder.

---

7. Running tests and results

How a run starts

• You press Run test in the top bar when you have a request or a saved example (test example) of that request selected.
• If in the workspace tree you have more than one item selected (two or more requests and/or saved examples), the same button starts parallel execution described in the next subsection.
• If your account cannot run (for example inactive subscription), the app may first show a plan upgrade dialog instead of the normal flow.

Parallel execution (multi-test run)

When there are at least two executable items in the tree multi-selection (requests and/or saved examples), Performate launches all those runs at once (in parallel): each opens its external terminal with k6 and uses the same variable environment active in the bottom panel.

• What runs: for each selected request, the generated script or that request’s custom script is used; for each selected saved example, its script is used (with {{variables}} substitution per the example configuration). The confirmation dialog list shows the names (up to 40 visible with scroll if needed).
• Internal order: selected requests are queued first, then examples; within each group, order follows selection order in the tree.
• Embedded dashboard: if you enable include dashboard and at least one of the selected items is not Monitoring, each eligible test gets its own live dashboard (each process uses a different port to avoid clashes). In the bottom panel a selector like «Show dashboard for…» appears to switch between runs while they run or when loading reports.
• Terminal only: Monitoring items in a parallel batch do not use the embedded dashboard for that row; you will see that that run was terminal only. If the entire batch is monitoring, the flow is several runs without an integrated dashboard in the app.
• Stop execution tries to stop all k6 processes the app started in that session, not just one.
• Results: each run that uses the report flow may generate its own HTML/JSON in the results folder, with the usual naming pattern.

Confirmation before running

The Run confirmation dialog opens with two main blocks:

1. Test Summary

• In parallel execution, the summary shows how many items will run, type «Parallel», the workspace, and text explaining the behavior; below, the list of names (requests and examples).
• Endpoint: for a normal request it is METHOD + URL (includes the query if it is GET and you have params). If you run a saved example, the summary may show the example name as a reference.
• Workspace: shows the workspace name you are working in. It is not the same as the variables “environment” in the bottom panel (Postman-style); it helps verify you are in the right project.
• Load / VUs: a value tied to the peak or load configuration (the English label may say “Max Virtual Users” even in RPS mode the number summarizes the load the app presents).
• Test type and duration (when applicable; in monitoring duration may not show the same way).
• Extra fields by type: for example spike count and rates in Spike, ramp or plateau times in Stress, etc.
• If the URL or texts contain {{variables}}, the summary may highlight them; hovering a truncated URL usually shows the full text in a tooltip.
• k6 binary: if you have built binaries with the xk6 builder, you can choose the bundled k6 or a custom one before launching.

2. Pre-run checklist
   Eight items grouped in four blocks; you must check them all (or use Mark all) to enable the run button:

• Dialog footer: warning that the test may generate a lot of traffic and affect the destination system.
• Cancel closes without running. Click outside or Escape usually also closes the dialog.

What happens when you run (terminal and files)

• The app writes the script to a temporary folder and launches k6 in an external terminal window (on Windows a console usually opens with a .bat you can inspect; Performate’s command and messages appear in that window). That way you see live logs and the process is not hidden only inside the UI.
• With k6 web report (usual case): for test types other than Monitoring, the app starts k6 with k6’s built-in web dashboard (K6_WEB_DASHBOARD), without opening the browser on its own at start, and defines an HTML report export (and summary data as JSON) in the user’s results folder. The file name usually follows a pattern like:
  TestName_TestType_YYYY-MM-DD_HH-MM.html
• Terminal only (no embedded dashboard in the app): for Monitoring the run is like classic k6 run: the web dashboard flow is not enabled in the app; you still see output in the terminal.

Bottom panel: Dashboard during and after the run

In the Dashboard tab of the bottom panel:

• While starting: a message like “Starting dashboard server…” or “Running…”. Stop execution appears to send a stop signal to k6 processes the app launched (useful if the test hangs or you want to cut early). With several parallel runs, this action applies to all instances started from Performate.
• Several runs at once: if you just used parallel execution, choose in the dropdown which run you want to see in the viewer; local URLs may use different ports per process. Rows marked terminal-only do not show an embedded dashboard for that item.
• Live dashboard: if all goes well, the k6 web dashboard view is shown at an http://127.0.0.1 URL with a port the app assigns (free ports from 5665 are often used; with several runs at once, each process has its own) inside an embedded viewer. You can use Open in browser to see it in your external browser (same address the viewer shows).
• Switch to HTML report: when the test finishes, k6 may export the HTML to your results folder; the app detects the file, stops showing only the live dashboard, and loads the static report (file://…) when ready. A message like “Closing dashboard… the report will load when ready” may appear.
• Clear: when the report is already a local file or the live dashboard failed, the action to clear the panel view is usually enabled so you can start fresh.
• If there is an error launching k6 or the dashboard, the panel may show the error message instead of the URL.

After a run with a report, the Test results list in the sidebar updates to include the new HTML. The History tab in the bottom panel also records the run (see below).

Results folder (sidebar)

The Test results section lists HTML reports stored under the profile data folder (usually something like …\Performate\data\<profile>\test_results\ on Windows; see Data on your machine).

• Expand / collapse the section to see the list. Button to open the folder in the file explorer and another to refresh the list.
• Double-click a file → opens the report with the system default application.
• Single click selects; Ctrl/Cmd + click allows multi-select.
• Drag and drop files onto the results root or onto a folder to move them (there is also a “Move to folder” dialog in the context menu).
• Right-click a file: AI summary (one file) or Compare reports (several selected), Show in explorer, Rename, Move to folder (if there are folders or the file is in a subfolder), Delete. With several selected, delete acts on all of them.
• Right-click the “Test results” header → New folder to organize reports. Right-click a results folder → Delete folder.
• With result files selected, Delete / Backspace may open deletion (if focus is not in a text field).

The app may also accept that you drag an HTML report onto the application area to open it or handle it per the configured flow (result import/view).

Run History

In the bottom panel, the History / Run History tab keeps a log of runs launched from the app (completed, canceled, or with error):

• Lists entries with name, status, date, mode (individual or parallel), and useful metadata (tags / scope as the UI shows).
• You can filter or narrow by request / scope when the UI offers it.
• Reopening an entry usually loads the summary or associated report in the Dashboard (if the file is still available).
• With several compatible entries you can compare results or generate an AI summary / comparison following the reports flow.
• You can delete history entries without necessarily deleting the HTML in Test results (they are different views: history = log; Test results = HTML files on disk).

---

8. AI summaries

Report summaries

• One report: right-click a result → option to generate an AI summary.
• Several reports: select at least two results and use the compare option; you get markdown text.
• Export the summary: PDF or Word (.docx).
• In the summary flow you can attach or paste screenshots (usual image formats, with size and count limits shown on screen) to give the AI visual context.
• On higher plans the app may offer context improvements (extra fields) when requesting the summary; quotas and tokens depend on the plan (see Section 9).

AI assistant for k6 scripts

Besides summarizing reports, Performate includes a chat / assistant that suggests changes to the k6 script (preview or saved example):

1. Open the script preview tab (or a saved example with a script editor).
2. Open the AI assistant from the control in the editor bar (AI icon or button).
3. Describe in natural language what you want (add checks, tags, thresholds, light refactor, etc.).
4. Review the diff or proposed text. Use Keep to apply changes to the editor, or Undo to discard them.
5. The assistant does not run the test for you and does not replace human review: if you ask for something out of scope (for example another tool), the app may reject it or limit the response.

Monthly limits (operations or tokens, depending on the plan) are enforced on the server; Free usually has low fixed quotas; Pro and Pro+ use broader token windows. See plans in section 9.

---

9. Account and subscription

Sign in or register

• Use email and password and, if the app offers it, Google.
• It is the same screen for sign-in and sign-up: if the email was not registered, the account is created at that moment.

Plans

• If the subscription has ended (e.g. expired Pro or Pro+) or the account is in an expired state, a screen may invite you to upgrade the plan or sign out.
• Without an active subscription, the app may limit actions such as running tests, using AI summaries, creating workspaces, or exporting reports, and show a message to update the plan.

Cloud sync (Pro and Pro+)

• Pro and Pro+ plans can sync encrypted workspaces and variables with Performate’s cloud service.
• On sign-in, the app restores what you have saved online if it exists; it also sends changes periodically and on close.

Single-device session

• If single session is enabled in your Supabase project, there can be only one signed-in session per account: if you sign in from another device, the previous session is invalidated and that app instance may sign out on its own when it regains focus. Technical detail: Single session per user docs in the app repository.

Run notifications (Pro+)

With Pro+ you can receive a notice when a run finishes:

1. Open the tools menu (or the Run notifications entry).
2. Enable the channel you want and fill in what each tab asks:
   • Telegram — bot token and chat ID.
   • Discord — Discord webhook.
   • Slack — Slack webhook.
   • Webhook — generic HTTP URL for your own receiver.
3. Save the configuration. On Pro+ settings may sync to the cloud with your account.
4. When a run finishes (success, failure, or cancellation per current design), Performate sends the summary to enabled channels.

Free and Pro may not have access to this feature; the UI may show an invitation to upgrade the plan.

Your account and options

In Options (gear / settings menu) you will find, among others:

• Account: email, plan, subscription status, trial, and expiry date when applicable (Pro / Pro+).
• AI keys (BYOK): optionally your own API keys for supported providers (e.g. Gemini / Qwen) if the build allows it; if you do not configure your own key, cloud quotas / proxy are used per your plan.
• k6 proxy: proxy configuration for runs when your network requires it.
• Check for updates and Report a bug on end-user builds.

---

10. Data on your machine

• The app stores your work in the user data folder. The main content is usually under Workspaces/<account>/ (workspaces + variables JSON). Datasets CSV and Test results reports are usually under data/<account>/ in the same Performate Roaming/local root (datasets and test_results; see the diagram below).
• The main files are workspaces.json (workspaces, folders, tests, examples, and, if you use them, each workspace’s JS library files — embedded in that same JSON —) and variables.json (environments and which one is selected).

Windows example (replace YourUser with your Windows user and email_local_part with the part of your email before @, as normalized by the app):

C:\Users\YourUser\AppData\Roaming\Performate\
├── Workspaces\
│   └── email_local_part\
│       ├── workspaces.json
│       └── variables.json
├── data\
│   └── email_local_part\
│       ├── datasets\      ← CSV and subfolders from the «Datasets» sidebar (see earlier in section 3)
│       └── test_results\  ← HTML reports listed as «Test results» (see section 7)

For example, if you sign in as ana.dev@company.com, a plausible path would be:

C:\Users\Ana\AppData\Roaming\Performate\Workspaces\ana.dev\workspaces.json

and your Datasets CSV would sit in parallel at C:\Users\Ana\AppData\Roaming\Performate\data\ana.dev\datasets\.

• Autosave: changes are saved as you edit; on close the application ensures everything is written to disk.
• For a portable backup, use the File → Import/Export → full backup hub.

---

11. Interface and language

Bottom panel

You can resize it. It includes these main tabs:

• Double-click panel or sidebar separators to collapse or expand.
• Short tips on configuration fields when you hover or focus the option.

View menu and zoom

From the View menu you can adjust full screen and UI zoom (depending on what your build offers).

Language

• UI language: Spanish and English (per the app selector).
• The updated web guide is at performate.app/en/guide (same documentation as this, product-oriented).

Options

See Your account and options in section 9: account, AI keys, k6 proxy, updates, and bug reports.

---

12. Tools

k6 utilities

• From the tools menu there is usually a guide about the recommended k6 version, a link to official k6 docs, and an action to check which k6 version the app uses on your machine.

Automation Hub

Modal to take a request into CI/CD without building the pipeline by hand:

1. Open it from the bar / menu (Automation Hub).
2. Choose the request in the side list (the app marks whether thresholds are already defined).
3. Requirements to generate full templates and commands:
   • A variable environment selected in the bottom panel.
   • Thresholds defined on the test (Validations tab) or, in a custom script, a recognizable thresholds block.
4. Use the tabs / templates:
   • GitHub Actions
   • Jenkins (Linux or Windows target)
   • Docker Compose with npx performate run
   • k6 Operator skeleton (Kubernetes; the ConfigMap script is a starting point)
   • npx performate run command consistent across tabs
5. Export CI starter: folder with package.json (and optionally your workspace/variables JSON) ready to version.
6. Optional: push to Git from the exported folder, or Run in CI locally (launches the command in a system terminal).

Access by plan: Pro+ has full access. Free and Pro can open the hub, but sensitive content may appear blurred until you upgrade. More detail in the app repository.

xk6 builder (custom binaries)

If you need k6 extensions (SQL, Kafka, etc. per the app catalog):

1. Open xk6 Builder from tools.
2. Choose extensions from the catalog (the UI warns if a dependency, e.g. SQL drivers, also requires the base module).
3. Optional: give the output binary a name (or leave the auto-generated one).
4. Press Build and wait for the logs. You can cancel a build in progress.
5. Binaries stay listed; you can delete them from the same screen.
6. When you run a test, in confirmation choose the bundled binary or one of the built ones.

Plans: building xk6 binaries requires Pro or higher (Free sees the option with an upgrade notice). The Automation Hub (Pro+) is independent. Detail in the app repository.

Run notifications

See Run notifications in section 9 (Pro+).

---

13. Frequently asked questions

Short answers for anyone arriving at the product or the landing; deeper technical detail continues in the rest of this guide, in the documentation hub, and in the app repository.

What is Performate?

Performate is a desktop app to design and run load tests with a flow similar to API tools, but oriented to performance: you define requests, scenarios, and data, and the engine that runs the tests is k6.

Why not just use the terminal with k6?

You can do that without trouble. Performate helps you organize the work: folders, reusable requests, per-environment variables, and a results panel without fighting every command or losing the thread across loose files.

Do I have to install k6 separately?

No. On usual Windows builds, k6 is already bundled in the application; you do not need to install it separately to start running from Performate. With Pro+ you can also build binaries with extensions (xk6).

Can I run multiple scripts in parallel?

Yes. You can run them in parallel; each run gets an independent dashboard and you can also create a comparative report of the runs. For how to select several requests or examples and launch them together, see Parallel execution (multi-test run).

Can I import what I already have in Postman?

Yes. You can import Postman collections (by dragging the JSON or from File → Import/Export) and avoid rewriting everything from scratch. Nuances are in Workspaces and organization.

Can I use Performate without an internet connection?

For standard use you need a connection to sign in, validate the account, and, if you have Pro/Pro+, to sync with the cloud. A prolonged “offline” mode is not intended for normal use.

Where are my data and scripts?

Scripts are uploaded encrypted to Supabase storage when you use cloud sync. On disk, the workspace JSON (Workspaces/<profile>/workspaces.json) includes requests, scripts, and the JS library; CSV datasets and HTML reports have typical paths under Performate/data/<profile>/ (see sections 3 and 10 of this guide). You can also make a full backup from the import/export hub.

Which operating systems is it available for?

Windows only for now. The project intends to expand compatibility to other operating systems later.

Can I write my own k6 script?

Yes. You can use custom scripts when the visual flow is not enough or you want full control of the k6 script. The AI assistant can propose edits; you decide whether to apply them.

What is the “JS library” in the sidebar?

It is a drawer of JavaScript files (.js / .mjs) per workspace: you store functions or code snippets that several tests can reuse without duplicating them. It is not the main test script; it is support material you link with import from the k6 editor. Concrete steps are in Section 3 — Workspace JS library.

Does the AI run the test for me?

No. AI does not replace you defining the load or k6 being the one that executes. It helps you understand results, summarize reports, or suggest changes to the script; you review and launch the run.

Is it useful if I am new to load testing?

Yes. The visual builder makes it easier to get started. If you already know k6, you still have the same engine underneath and the same concepts as always.

What are workspace and environments?

The workspace is your project: folders, requests, everything organized in one place. Environments let you change URLs, tokens, and more without duplicating the same test for development, staging, or production.

What are the free trial limits?

Limits depend on product version and Supabase policy. In the app, the Free plan often shows quotas on the order of 5 AI report generations and 5 k6 script AI assistant requests per month (server monthly window); Pro and Pro+ use different monthly token limits. For up-to-date figures, see the docs in the app repository.

Can I use Performate in CI/CD (e.g. GitHub Actions or Jenkins)?

Yes. The Automation Hub is built for that. Full access to templates and commands is for Pro+. Free and Pro can explore the modal, but some content may be restricted until you upgrade. Detail in the app repository and in SUBSCRIPTION.md.

What do I see while the test runs?

An in-app dashboard with typical k6 metrics (load, timings, errors, etc.), without relying only on console text. After it finishes, History and the Test results folder keep the run and the HTML.

Can I share a workspace with my team?

Yes, with Pro+. Use Team mode in the sidebar, share the workspace, and invite by email with view / run / edit permissions. See Team workspaces.

What is the xk6 builder for?

To compile a k6 with extensions (app catalog) when the bundled binary is not enough. Available from Pro upward. Then you choose that binary in run confirmation. See Section 12.

How do I get a notice when a test finishes?

With Pro+, configure Run notifications (Telegram, Discord, Slack, or webhook). See section 9.

Where do I see the history of my runs?

In the History tab of the bottom panel (in addition to the HTML in Test results). See section 7.

How do I make a full backup?

File → Import/Export menu → full backup. To restore, use the restore backup option in the same hub. See section 3.

---

14. More information

If you need more detail (local files, account, AI, or integrations), continue here:

• Section 13 — Frequently asked questions in this guide.
• The site documentation hub, Account and subscription, and pricing for current policies.
• Deeper technical product docs in the performate-app repository under documentation/ (e.g. SETUP, SUBSCRIPTION, AUTOMATION-HUB, WORKSPACE-STORAGE).

---

If your organization uses a custom build, follow the instructions they provided.