docs: document AGENT_WORKER_COUNT for private location agents

platform/private-locations/agent-configuration.mdx

@@ -13,7 +13,8 @@ Variable|Description
 `API_KEY`|API key for the Private Location in which the agent will serve. The API key is shown in the web app once, when initially creating a Private Location.
 `HTTPS_PROXY`|HTTPS proxy configuration for the outbound connection to the Checkly API, used for agent management and monitoring. `https://user:password@127.0.0.1:8080`
 `HTTP_PROXY`|HTTP proxy configuration for the outbound connection to the Checkly API, used for agent management and monitoring. Used if the proxy server does not accept HTTPS connections. `http://user:password@127.0.0.1:8080`
-`JOB_CONCURRENCY`|(Default: 1, max: 10) Number of concurrent checks that are run by the agent.
+`JOB_CONCURRENCY`|(Default: 1, max: 10) Number of concurrent Browser, Multistep and Playwright checks that are run by the agent. Not used by the [uptime image](/platform/private-locations/agent-images#uptime-image).
+`AGENT_WORKER_COUNT`|(Default: 10, max: 50) Number of concurrent API checks and uptime monitors (URL, TCP, DNS, ICMP) that are run by the agent. Applies to agent v7.0.0 and later. Values above 50 are capped to 50.
 `LOG_LEVEL`|(Default: `INFO`) Set the log level of the agent. Can be one of `DEBUG`, `LOG`, `INFO`, `WARN` or `ERROR`.
 `USE_OS_DNS_RESOLVER`|When set to true, TCP monitors will resolve DNS using `getaddrinfo` C function, instead of using the network. This enables easier DNS resolution for internal services e.g. services running in the same Kubernetes cluster.
 `DEPENDENCY_CACHE`|(Default: `OFF`) Set to `CHECKLY_S3` to enable dependency caching for [Playwright Check Suites](/detect/synthetic-monitoring/playwright-checks/overview). Caches installed dependencies between runs to speed up check execution. Learn more about [dependency caching](/detect/synthetic-monitoring/playwright-checks/custom-dependencies#dependency-caching).
@@ -28,10 +29,10 @@ docker run -e API_KEY="pl_...." -d checkly/agent:latest
 
 Here are some more usage examples:
 
-1. Set the `JOB_CONCURRENCY` to the appropriate value (1-10) based on your scaling calculations:
+1. Set the `JOB_CONCURRENCY` (1-10) and `AGENT_WORKER_COUNT` (1-50) to the appropriate values based on your [scaling calculations](/platform/private-locations/scaling-redundancy):
 
 ```bash Terminal
--e JOB_CONCURRENCY=10
+-e JOB_CONCURRENCY=4 -e AGENT_WORKER_COUNT=20
 ```
 
 2. Configure an HTTPS or HTTP proxy if one is required for your environment:

platform/private-locations/agent-images.mdx

@@ -45,7 +45,7 @@ Use the standard image unless you have a specific need for the dev or uptime var
 
 The uptime image (`checkly/agent-uptime:X.Y.Z`) is a lightweight version of the agent designed for [uptime monitoring](/detect/uptime-monitoring/overview) only.
 
-It supports URL, DNS, TCP and ICMP monitors.
+It supports URL, DNS, TCP and ICMP monitors. Concurrency is controlled by `AGENT_WORKER_COUNT`; `JOB_CONCURRENCY` has no effect on this image. See [agent configuration](/platform/private-locations/agent-configuration).
 
 ## Dev Image
 

platform/private-locations/scaling-redundancy.mdx

@@ -24,21 +24,25 @@ containers. Scaling out means adding additional agent containers.
 ## Scale up
 
 Scaling up of individual agents is generally memory-constrained. For reference, a Browser check requires about
-1.5GB of RAM and an API check requires about 150MB. The number of concurrent checks allowed to run on a single agent is
-controlled by the `JOB_CONCURRENCY` environment variable which defaults to 1 and can be increased to 10. We do not
-automatically separate browser and API checks on an agent. If you are running only Browser checks or a combination of
-browser and API checks in a Private Location, the formula (rounded down) is:
+1.5GB of RAM and an API check requires about 150MB. Two environment variables control how many checks a single agent runs
+at the same time:
+
+- `JOB_CONCURRENCY` (default 1, max 10) for Browser, Multistep and Playwright checks.
+- `AGENT_WORKER_COUNT` (default 10, max 50) for API checks and uptime monitors (URL, TCP, DNS, ICMP).
+
+We do not automatically separate browser and API checks on an agent. If you are running Browser checks in a Private
+Location, the formula (rounded down) is:
 
 `JOB_CONCURRENCY = Container memory allocation (GB) / 1.5`
 
 For example: if your container has 8GB of memory allocated, you should set `JOB_CONCURRENCY` to 5 (8GB / 1.5GB per check).
 
-If your Private Location is only running API checks:
+If your Private Location is only running API checks or uptime monitors, for example on the
+[uptime image](/platform/private-locations/agent-images#uptime-image), size `AGENT_WORKER_COUNT` instead:
 
-`JOB_CONCURRENCY = Container memory allocation (GB) / 0.15`
+`AGENT_WORKER_COUNT = Container memory allocation (GB) / 0.15`
 
-For example: if your container has 1GB of memory allocated, you should set `JOB_CONCURRENCY` to 6 (1GB / 0.15GB per API check).
-With 1.5GB of memory you can set `JOB_CONCURRENCY` to the maximum value of 10.
+For example: if your container has 1GB of memory allocated, you should set `AGENT_WORKER_COUNT` to 6 (1GB / 0.15GB per API check).
 
 ## Scale out
 
@@ -48,11 +52,12 @@ frequently as every 1 minute.
 
 Based on your configuration, you should be able to estimate how many checks will run per minute in your Private Location.
 API checks have a maximum running time of 30 seconds, Browser checks 4 minutes. This means that in the worst case scenario,
-a checkly agent with a `JOB_CONCURRENCY` of 1 can run two API checks per minute, or 1 Browser check per 4 minutes.
-In an average configuration this will be higher and API checks are generally faster than Browser checks.
+a checkly agent can run two API checks per minute per `AGENT_WORKER_COUNT` slot, or 1 Browser check per 4 minutes per
+`JOB_CONCURRENCY` slot. In an average configuration this will be higher and API checks are generally faster than Browser checks.
 
-Once you have an idea of how many checks will be running and you know the per-agent `JOB_CONCURRENCY` limit based on the
-agent container memory allocation, you can estimate the number of agents required as
+Once you have an idea of how many checks will be running and you know the per-agent concurrency limit based on the
+agent container memory allocation, you can estimate the number of agents required as follows. Use `JOB_CONCURRENCY` for
+Browser checks and `AGENT_WORKER_COUNT` for API checks and uptime monitors:
 
 `agents = ((Checks per minute * average check duration in minutes) / JOB_CONCURRENCY) + 1`