Key takeaways
- In LoadFocus, give each service entry point its own saved test, with its own pass/fail thresholds, so a failing run names the service.
- Put the test in the pipeline with the GitHub Action, the verdict API or the Jenkins plugin, and schedule the same test for the runs that are too long for a build.
- LoadFocus measures from the outside, over HTTP. Server-side CPU, queues and traces still come from your own observability stack.
This post covers the LoadFocus workflow for microservices. The general method (service-level versus end-to-end tests, mocks, autoscaling, circuit breakers, tracing) is in Load Testing Microservices in Cloud Environments, so it is not repeated here. Every LoadFocus feature below was read off loadfocus.com and its documentation on 2026-10-23; anything that page does not confirm is marked as unconfirmed.
How do you automate load testing for microservices with LoadFocus?
Create one saved test for each service entry point you care about (an API gateway route, a service’s own API), set pass/fail thresholds on each, run those tests from a CI/CD pipeline after every deploy to staging, and schedule the longer runs so they repeat without anyone starting them. A failed threshold gives you a FAIL verdict for that service, and the pipeline can block the release on it.
The rest of this post goes through those steps in order.
What does LoadFocus need to reach your services?
LoadFocus runs tests from its cloud load generators, so a test can only call endpoints those generators can reach: a public staging URL, or an environment that allows traffic from the test locations. The new-test documentation links to location details and IP whitelisting information for that purpose. Services that sit on a private network behind your cluster need either an ingress that the generators can reach or a gateway route set up for the test.
That has a design consequence. A LoadFocus test exercises the same front door your users or other systems use. It does not call service B directly from inside the cluster, so for service-to-service behaviour you test the public routes that cause those calls.
How do you set up a test for one microservice?
Open the new-test page and work through the sections the documentation lists:
- Test name and location. Pick the region the virtual users send requests from. The load testing page lists 25 cloud regions and says a test can use several locations.
- Load scenario. Start from one of the predefined scenarios (Initial Load, Warm-up Load or Moderate Load) and adjust.
- Test configuration. Set virtual users, duration (or a number of iterations instead), ramp-up time and ramp-up steps. A chart previews the ramp before you run.
- Requests. Enter the endpoint, choose the HTTP method (GET is the default), and add more requests if the journey needs them. Every virtual user runs the requests in sequence, and you can reorder them.
- URL options. Add query parameters. The product page also lists headers, cookies and Basic HTTP authentication.
Use the ramp-up steps for microservices. A service that scales out or opens connection pools reacts to a gradual rise differently from a wall of users at second zero, and the preview chart shows exactly which of the two you configured. Validating infrastructure auto-scaling with load testing explains how to read the ramp against scaling events.
The free plan runs up to 10 virtual users, and the load testing page lists up to 20,000 concurrent virtual users per test on larger plans. Check your target against your plan on loadfocus.com/pricing before you plan the test.
Which services should get their own test?
Not every service needs one. Start with the entry points where a slow answer hurts a user or a revenue flow, then add the services that failed in past incidents.
| Candidate | Why it earns a saved test | Typical thresholds to start from |
|---|---|---|
| Authentication or session service | Every journey starts there | Tight p95, near-zero error rate |
| Checkout, payment or order route | Direct revenue impact | Tight error rate, steady throughput |
| Search or catalogue API | Highest request volume | Throughput floor, p99 |
| A service that failed in a past incident | The regression most likely to return | The limit it broke last time |
| An internal service with one caller | Usually covered by the route above it | None until it causes trouble |
The numbers are yours to set. Take them from your service-level objectives, and when you have none, from a first baseline run of the same test.
How do you make a test fail when a service gets slower?
Use pass/fail thresholds. According to the LoadFocus documentation, you can set four limits per test and leave any of them empty to skip that check:
- max P95 response time (ms)
- max P99 response time (ms)
- max error rate (%)
- min throughput (requests per second)
Tick Enable pass/fail thresholds on the test page. Each run then gets a PASS or FAIL badge, and under it every check shows the actual value, the target and whether it passed. Thresholds work for cloud, JMeter and k6 tests, and the Trend tab plots P95, error rate and throughput across runs with your limits drawn as lines, so a slow drift shows up before it crosses the line.
Because thresholds are saved per test, a one-test-per-service layout gives you a per-service verdict for free. A single test that mixes ten services into one set of numbers cannot say which of them caused the failure. Why percentiles beat averages in performance testing explains why the limits are P95 and P99 and not an average.
How do you run LoadFocus tests from CI/CD?
The load testing page and documentation describe four routes. Pick the one that matches your pipeline.
| Route | What it does | Source |
|---|---|---|
| GitHub Action | Runs a test, waits for it, reads the verdict and exits non-zero on a breach, which fails the workflow step | Pass/fail thresholds documentation |
| Verdict API | GET /api/v1/{loadtests|k6tests|jmetertests}/verdict?testrunname=<name>&testrunid=<id> on a finished run returns verdict, checks and metrics | Pass/fail thresholds documentation |
| Thresholds API | PUT, GET and DELETE on /api/v1/{loadtests|k6tests|jmetertests}/thresholds set, read or clear the limits from a pipeline | Pass/fail thresholds documentation |
| Jenkins plugin | Defines limits that mark a build UNSTABLE or FAILED | Load testing page |
There is also an API client for JMeter tests. Its documentation shows a command that starts a test, waits and applies thresholds in one step:
npm install -g @loadfocus/loadfocus-api-client
loadfocus-api config set --apikey "$LOADFOCUS_API_KEY" --teamid "$LOADFOCUS_TEAM_ID"
loadfocus-api jmeter run-test --name "checkout-service" \
--thresholds "avgresponse<=200,errors==0,p95<=250"Store the API key and team ID in your CI secret store, as the placeholders above suggest, and never in the repository. The documentation does not state which exit code a failed threshold returns, so run one deliberately failing test in a throwaway branch and confirm that your pipeline step goes red before you rely on it as a gate.
The load testing page names Jenkins, GitHub Actions, GitLab CI, CircleCI, Bitbucket Pipelines and Azure DevOps as pipelines the verdict API can serve, and the documentation has a guide for five of them.
Where should the test sit in the pipeline?
Keep the build fast and the heavy runs elsewhere.
- On every deploy to staging: a short test per changed service with tight thresholds. Its job is to catch an obvious regression, so a few minutes is enough.
- On a schedule: the long and large runs, covered below.
- Before a major release: a stress run you start by hand and read yourself.
Only the services that changed need the per-deploy test. Running every service’s test on every commit is the quickest way to make a team ignore the pipeline. Comparing load testing tools for CI/CD looks at how the common tools fit into a pipeline.
How do you schedule recurring microservices tests?
Scheduling is available on paid load testing plans for cloud, JMeter and k6 tests. On the test page, tick Enable recurring schedule, choose daily, weekly or monthly (monthly uses a day from 1 to 28), set the time and timezone, and click Save schedule to see the next run.
Scheduled runs email the test owner when a run fails its thresholds or fails to complete. A passing run sends no email, and a test without thresholds only alerts on completion failures. That is one more reason to set thresholds on every scheduled test: without them a slow service passes silently.
Two practical uses for microservices:
- A nightly baseline of each critical route against the staging environment, so a regression introduced three releases ago still shows up.
- A weekly larger run that is too long to put in a pipeline.
How do you read the results for a distributed system?
LoadFocus reports response time, latency, hits per second, throughput, standard deviation and the 50th, 90th and 99th percentiles, with error and response-code charts that show when errors started and how many virtual users were active at that moment. Edit and re-run a test to compare how performance changes as load changes, and use the Trend tab to compare runs over time.
For a pipeline there is an analysis API (GET /api/v1/{loadtests|k6tests|jmetertests}/analysis) that returns the numbers behind the verdict as JSON, including exact percentiles, error types and per-request and per-region metrics. Per-request numbers matter for microservices because a multi-step test passes through several services, and the slowest request tells you which one to open first.
Check the load generators too. The documentation on load generator saturation says a generator running near 100% CPU cannot send at the configured rate and records its own waiting time as response time. The Overview shows a warning banner when an engine peaked at 80% CPU or higher. If you see response times rising with virtual users while your service looks idle, read the Engine Health tab before you blame the service.
What LoadFocus does not show you
LoadFocus reports what the load generators measured at the HTTP layer. It does not show which downstream service inside the cluster slowed down, how full a queue was, or how the autoscaler behaved. Pair each run with your own metrics and traces for the same time window. The cloud microservices guide covers how to correlate a test with traces, and how to optimise database connection pools covers one of the most common causes you will find.
The LoadFocus pages do not mention gRPC or message-queue protocol tests, so treat those as unconfirmed and check the documentation, or contact LoadFocus, if your services depend on them.
Can you reuse JMeter or k6 scripts for microservices?
Yes. The load testing page says existing JMeter scripts run unchanged from the cloud regions, and the documentation has guides for uploading k6 scripts and data files and for importing cURL, HAR, Postman or OpenAPI definitions into a JMeter test. A script is the right choice when a journey needs login, tokens, correlation between responses and requests, or per-user data from a file, which the form-based test does not cover. The pass/fail thresholds apply to those tests as well. Running k6 at scale compares the options for larger k6 runs.
The LoadFocus page for JMeter load testing and the k6 load testing page describe the two script routes.
Can LoadFocus also monitor the same services between tests?
The API monitoring product runs scheduled checks against an endpoint, validates status codes, response times and JSON bodies, and alerts through channels such as email, Slack, Microsoft Teams, PagerDuty and webhooks. Check frequency and locations per check depend on the plan. A common pattern is to load test a route before release and monitor it afterwards with the same assertions. The API monitoring page also says a slowing endpoint can be load tested from the same account to find its limit.
Checklist: automated load testing for microservices with LoadFocus
| Step | Action | Done when |
|---|---|---|
| 1 | List the entry points that matter | You have 3 to 5 routes, not every service |
| 2 | Confirm the generators can reach them | A single-user run returns the expected status |
| 3 | Create one saved test per route | Each has a ramp, a duration and realistic requests |
| 4 | Set pass/fail thresholds | Every test shows a PASS or FAIL badge |
| 5 | Wire the verdict into the pipeline | A deliberately failing test turns the build red |
| 6 | Schedule the long runs | The next-run date is visible and alerts reach a person |
| 7 | Pair runs with your own telemetry | You can open the traces for any run’s time window |
Frequently Asked Questions
Can LoadFocus test microservices inside a private network?
LoadFocus tests run from its cloud load generators, so the endpoint must be reachable from them. The documentation links to the test locations and IP whitelisting information so you can allow that traffic. Services with no route from outside need a gateway route or an ingress created for the test.
Should I write one test for the whole system or one per service?
One per entry point. A per-service test gives each service its own thresholds and its own verdict, while one combined test hides which service failed. Add a small end-to-end journey test on top for the flows that cross services.
How do I fail a pipeline when a service is too slow?
Set pass/fail thresholds on the saved test, then use the GitHub Action, the verdict API or the Jenkins plugin to read the verdict. The GitHub Action exits non-zero on a breach. Confirm the failing path with a deliberate failure before you depend on it.
Does LoadFocus replace tracing and monitoring?
No. It measures from the load generators’ side and gives you response times, errors and throughput. Use your own traces and metrics to see inside the cluster.
Can I run the same test on a schedule?
Yes, on paid plans. Choose daily, weekly or monthly, a time and a timezone. The owner is emailed when a scheduled run fails its thresholds or does not complete.
Sources
- loadfocus.com/load-testing and loadfocus.com/index.md (read 2026-10-23)
- LoadFocus documentation: new load test, pass/fail thresholds, scheduled load tests, load generator saturation, CI/CD integration and API client (loadfocus.com/docs, read 2026-10-23)
- loadfocus.com/api-monitoring (read 2026-10-23)
