LoadFocus glossary

Short definitions of the terms you meet in the app and in these docs, grouped by product. Each one links to the page that covers it in full.

Load test setup

• Virtual user (VU): a simulated user that sends the requests of your test one after another, for the whole test. The number of virtual users is how many people the test acts as at once. See What are Virtual Users in Load Testing.
• Load generator: a cloud machine that runs virtual users and sends their requests to your site. A test uses one or more load generators in each location. See Load Generator Hardware.
• Engine: the name the results page gives a load generator, as in "engine 2 peaked at 91% CPU" and the Engine Health tab of JMeter runs. See Load Generator Saturation.
• Ramp-up time: how long the test takes to go from zero to the full number of virtual users. See What is Ramp Up Time in Load Testing.
• Ramp-up steps: the number of steps in which virtual users are added during the ramp-up time. More steps give a smoother ramp. See What is Ramp Up Steps in Load Testing.
• Delay: Delay (ms) is the pause between the start of one virtual user and the start of the next, so they do not all send their first request at the same instant. See What is Delay when running a Load Test?.
• Duration: how long the test sends load, set in seconds. See What is Duration in Load Testing.
• Iteration: one pass of a virtual user through all the requests of the test. With Run by iterations instead of time, each user runs a set number of iterations. In k6 tests the iterations are shared: the users run that many iterations in total, starting at once. See What Are Iterations in Load Testing?.
• Location: the cloud region the load generators run in. Paid plans can choose any of the 25 locations. See Geographical Test Location in Load Testing.
• Schedule: runs a test automatically at the times you set, and emails you when a run fails its thresholds or does not complete. See Scheduled Load Tests.
• Pass/fail threshold: a limit, such as a maximum response time or error rate, that marks each run as passed or failed automatically. See Pass/Fail Thresholds.
• AI credits: what AI analyses of results and Create with AI use: 1 credit per analysis. Every plan includes some per rolling 30 days. See AI Credits.

Load test results

• Test run ID: the number of one run of a test. Each run gets the next number for that test name, shown as Run on the Overview tab. See What is a Test Run Id?.
• Sample: one request recorded by a load generator, with its response time and result. Samples on the Overview is the total number of requests sent. See What are Samples in Load Testing?.
• Hits/sec: the number of requests your application receives each second. The Overview shows the average for the run. See How to Check Load Test Results.
• Throughput: how much work the test pushes through per second, counted in requests (hits/sec) or in kilobytes sent and received, as on the Insights tab. See Load Testing Insights.
• Percentile (P90, P95, P99): the response time that 90%, 95% or 99% of the requests were faster than. Percentiles show the slow tail that an average hides. See Decoding Average Response Time.
• Error rate: the share of requests that failed, with a 4xx or 5xx response or a connection error. The Overview shows it as Errors %. See Errors by Type and Error Rate.
• Baseline: a run you pin as the reference point. Six headline metrics of other runs then show the percentage change against it. See Baseline Comparison Between Load Tests.

API Monitoring

• Check: a test of your API or site that LoadFocus runs on a schedule from the locations you choose: API, multistep, browser, DNS or TCP. See How to Create a New API Check.
• Check run: one execution of a check from one location. A multistep check counts one run per step. Plans include a number of check runs per month. See Plans and limits.
• Heartbeat monitor: a monitor for scheduled jobs. Instead of LoadFocus calling your service, your job calls LoadFocus each time it finishes, and the monitor goes down when the call does not arrive in time. See Heartbeat (Cron Job) Monitors.
• Alert channel: where alerts are sent: email, Slack, Microsoft Teams, webhook, Discord, PagerDuty or Opsgenie. See Alert Channels.
• Maintenance window: a time range during which alerts are silenced for the checks you select. The checks keep running and recording results. See Maintenance Windows.
• Snippet: a reusable piece of JavaScript you save once and load into check scripts with require(). See Snippets.
• Setup and teardown scripts: JavaScript that runs once just before a check (setup) and once just after it (teardown), for example to fetch a token or clean up test data. See Setup and teardown scripts.
• SLO and SLA: an SLO target is the uptime you aim for on a monitor, for example 99.9%. The SLA report is the recurring email that shows uptime against that target. See SLA & SLO Uptime Reports.
• Error budget: the downtime your SLO target allows in the period. A 99.9% target over 30 days allows roughly 43 minutes. When the budget is used up, the SLO is breached. See SLA & SLO Uptime Reports.
• Status page: a public page that shows the current status of the monitors you choose. See Create a Public Status Page for Your Monitors.

Page Speed Monitoring

• Test: in Page Speed Monitoring, a Lighthouse-based check of one URL from a location you pick, on a schedule you control. See Create New Website Performance Test.
• Monitor: the alert rule you attach to a Page Speed test. It notifies you when a score or metric crosses the value you set. See Create a New Alert.
• Lighthouse score: four scores from 0 to 100, Performance, Accessibility, Best Practices and SEO, each summing up a whole category of checks. See Alert Metrics.
• Core Web Vitals: the three metrics Google uses to rate page experience. See What are the Core Web Vitals?.
  • LCP (Largest Contentful Paint): how long the largest text block or image takes to appear. Measures loading.
  • INP (Interaction to Next Paint): how long the page takes to respond visibly to a click, tap or key press. Measures responsiveness.
  • CLS (Cumulative Layout Shift): how much the content moves around while the page loads. Measures visual stability.
• Lab data and field data: lab data comes from a single controlled test run, like a Page Speed test. Field data comes from real visitors over time, such as the 28 days of the Chrome UX Report or your own RUM data. See Real-User Field Data (CrUX).
• RUM (real user monitoring): Core Web Vitals measured in the browsers of the people who visit your site, through a small script you add to your pages. See Real User Monitoring (RUM).