--- title: Core concepts description: Workspaces, products, tests, executions, monitors, metrics, channels, agents, and devices, and how they fit together. lastUpdated: "2026-09-23" --- > **For AI agents:** the complete documentation index is at [llms.txt](/llms.txt). Append `.md` to any page URL for its markdown version. Nine terms come back everywhere in Kapptivate. This page defines each one and shows how they fit together, so the rest of the documentation reads without friction.
Workspace
Product Aweb portal
Test 1web
Execution 1, on the Chrome agentsuccess
Execution 2, on the Firefox agentfailed
Test 2smartphone
Monitor 1Test 1, promoted, runs dailyup
DevicesChrome browser, iPhone 12, Samsung Galaxy
Product BSIM-based service
Test 3cellular
DevicesSIM card 1, SIM card 2
AgentsWeb, Smartphone, Cellular
When you run Test 1 on the Chrome agent, an execution is created, the agent controls the browser, and results are recorded. Later, you can promote Test 1 to a monitor, which runs on a schedule and tracks health over time. ## Workspace A **Workspace** is your organization's operational unit. It contains all your products, devices, tests, agents, users, and results. Think of it as a container for a customer or a major business unit. When you log in to Kapptivate, you choose a Workspace. All your work within that Workspace is isolated from others. A Workspace can be active (in use) or archived (inactive), and you can be a member of several. You don't need to log out to move between Workspaces. Click your workspace name at the top of the sidebar and open **Switch workspace**: search a workspace by name, pick one from your recent list, or click **View all** to browse every workspace you belong to. ## Product A **Product** is a specific app or service being tested within a Workspace. A single Workspace can hold several products of different kinds: a web portal, an Android or iOS mobile app, a SIM-card-based service, and so on. Tests, monitors, configurations, and devices are all scoped to a Product. When you switch products in the sidebar, you change which tests and devices you see. You can set a default product for each Workspace, and the platform jumps to it when you enter. Access is managed per product space. [Roles](/administration/roles) grant specific people access to specific products, and [devices](/equipment/devices-lab) can likewise be restricted to specific products. ## Test A **Test** is a reusable automated sequence that exercises a specific feature or workflow. You define it once, then run it as many times as you need. A test is organized into **step groups**, and each step group contains **steps**: - A **step group** is a functional unit: *Log in*, *Buy an item*, *Run a search*. It bundles everything needed to accomplish one higher-level action. - A **step** is a single unitary action inside a group: click an element, type text, navigate, wait, or check state. This two-level structure keeps tests readable: you see the workflow at a glance through its step groups, then drill into a group to see the individual steps. Every test starts from a starting point (a URL to navigate to, or an app to launch) before running its step groups. A test also uses: - **Variables**: parameterized inputs so you can run the same test with different data. - **Checks**: validation statements that verify the application's response (page content, load time, etc.). Tests can reference [reusable components](/tests/reusable-components) (other tests used as building blocks) to reduce duplication. Once a test is written and approved, it can be run on-demand, on a schedule, or as part of CI/CD. ## Execution An **Execution** is a single run of one or more tests against specific devices. When you queue a test to run, the platform creates an execution. That execution produces detailed results: screenshots, step logs, timing, and final status. Executions have statuses like success, failed, warning, ongoing, canceled, or timed out. You can run a test multiple times and get multiple executions. Each execution is independent and preserves its results forever, so you can go back and investigate failures weeks later. ## Monitor A **Monitor** is a test promoted to continuous production supervision. Instead of running once and stopping, a monitor runs on a recurring schedule and tracks the application's health over time. Monitors have statuses: up (healthy), degraded (partial failure), or down (critical failure). When a monitor's status changes unexpectedly, it raises an **Incident**, an alert you can see in the Overview and respond to. Monitors are how you catch production issues before your users do. Create a monitor from any test once it's proven reliable. ## Metric A **Metric** is a measurement captured when a test or monitor runs, such as a response time or a success status. Metrics turn raw runs into data you can track and chart over time, and they apply to both tests and monitors. Some metrics are built in, for example USSD session-opening time or a mobile app's load time. You can also define [custom metrics](/tests/actions/shared/createmetric) for whatever you need to measure. Every step produces a duration, and every step group produces one too, so timing data is available at each level of a test without extra setup. ## Channel A **Channel** is a broad category of endpoints you test: Web, Smartphone, or Cellular. Each channel has its own device types and agents. On top of these, **APIs** can be tested as well, through API steps inside any channel's tests. - **Web**: test desktop and mobile browsers. - **Smartphone**: test native iOS and Android apps. - **Cellular**: test SMS, USSD, or cellular-dependent flows. - **API**: test HTTP endpoints with API steps inside a Web or Smartphone test. A simple test runs on a single channel, optionally paired with API, for example Web only, Web + API, Smartphone + API, or USSD (SIM) + API. For more complex flows, advanced orchestration lets a single test span multiple devices: start a scenario on Web and finish it on a Smartphone, for instance. ## Agent An **Agent** is the hardware or software component that controls the devices your tests run on. There are a few types: - **Web Agent**: physical or virtualized. Controls web browsers (Chrome, Firefox, Safari, etc.). - **Smartphone Agent**: physical. Controls real Android or iOS devices. - **Cellular Agent**: always physical. Controls SIM cards to test SMS and USSD, run network tests, place and receive calls, browse data, and more. - **Passive Agent**: collects metrics and health data without running active tests. You can create agents and register them in the platform through your administrator. When you run a test, you pick which agent(s) to run it on. ## Device A **Device** is the endpoint being tested, the thing the agent controls. Devices include: - **Web browsers**: Chrome, Firefox, Safari running on a Web Agent. - **Smartphones**: physical or virtual iOS/Android phones connected to a Smartphone Agent. - **SIM cards**: cellular lines registered with a Cellular Agent for SMS and network testing. You can see which devices are available (and their current status: online, offline, busy) in the Equipment section of the sidebar. See [Statuses](/equipment/statuses) for the full status reference. ## What's next? Create your first test, run it, and read the result How browser and HTTP tests run on the Web agent Native app testing on real Android and iOS devices USSD, SMS, and network tests on real SIM cards