For teams with a k6 script who want it run against staging and the thresholds reported. Certyn is not a load-testing service: it runs your script on one Machine.
Your setup
- A k6 script in your repo, with thresholds (for example
http_req_duration: ['p(95)<500']). - A staging service to put load on.
- A self-hosted runner, so you choose the Machine's size.
- You want a pass or fail on the thresholds, on demand or after a deploy.
Say this to Certyn
Run our k6 script loadtests/checkout.js on our runner against staging and tell me which thresholds failed.
What Certyn does
- If you have no runner yet, opens the runner form. Add
-e WORKSPACE_PATH=/srv/certyn-workspace \to its command. - Opens a form for the repo token (
GH_TOKENfor GitHub). - Downloads the k6 binary into
/workspaceonce. - Runs the script with the environment URL, for example
k6 run -e BASE_URL=$TARGET_BASE_URL loadtests/checkout.js. k6 exits with an error when a threshold fails. - Reads the k6 summary and writes the report.
What you get
- A report with each threshold, passed or failed, and the measured value, plus failed checks and error rates.
- If you ask: the same goal as an agent process, after each deploy or every night.
Limits
- The load comes from one Machine: one container, one host, one IP address. By default a runner gives each Machine 1 CPU core and 2.5 GB of memory. Raise it on the runner command with
-e CONTAINER_CPU_CORES=4 -e CONTAINER_MEMORY_GB=8(up to 16 each). - That is enough for a baseline or a small load test. For high or distributed load, use a load-testing service.
- A cloud Machine can run a small script, but you cannot change its size.
- One shell command can run 30 minutes; longer tests run in the background. A run has 60 minutes by default (up to 4 hours); a scheduled or deploy-triggered run has 60 minutes.
- Put load on staging, not production.