Fill gaps from assistant conversations: scaler value and Pod min fields

sdks/graphql/manage-pods.mdx

@@ -1,4 +1,4 @@
 ---
 title: "Manage Pods"
 description: "Create, start, stop, and query Pods using the GraphQL API. Review authentication, operations, request patterns, and examples for this Runpod SDK."
 ---
@@ -18,10 +18,12 @@
 | Get Pod by ID | `pod(input: {podId: "..."})` |
 | List GPU types | `gpuTypes` |
 
 ## Create a Pod
 
 Pods provide guaranteed compute at a fixed price.
 
+The `podFindAndDeployOnDemand` mutation searches for an available machine that matches your input, then deploys a Pod on it. Fields prefixed with `min` (such as `minVcpuCount` and `minMemoryInGb`) set minimum requirements that a machine must meet. They don't set fixed allocations. The vCPU and memory your Pod receives depend on the machine Runpod selects.
+
 <Tabs>
 <Tab title="cURL">
 ```bash
@@ -83,9 +85,9 @@
 </Tab>
 </Tabs>
 
 ### Filter by CUDA version
 
 Use `allowedCudaVersions` to restrict Pods to machines with specific CUDA versions.
 
 <Tabs>
 <Tab title="cURL">
@@ -123,7 +125,7 @@
 </Tab>
 </Tabs>
 
 ## Start a Pod
 
 Resume a stopped Pod using the `podResume` mutation.
 
@@ -164,7 +166,7 @@
 </Tab>
 </Tabs>
 
 You can also filter by CUDA version when starting a Pod:
 
 ```graphql
 mutation {
@@ -179,7 +181,7 @@
 }
 ```
 
 ## Stop a Pod
 
 Stopping a Pod releases the GPU while preserving your volume data.
 
@@ -218,9 +220,9 @@
 </Tab>
 </Tabs>
 
 ## Query Pods
 
 ### List all Pods
 
 <Tabs>
 <Tab title="cURL">
@@ -305,7 +307,7 @@
 </Tab>
 </Tabs>
 
 ### Get Pod by ID
 
 <Tabs>
 <Tab title="cURL">
@@ -384,11 +386,11 @@
 </Tab>
 </Tabs>
 
 ## Query GPU types
 
 List available GPU types to find the `gpuTypeId` needed when creating Pods.
 
 ### List all GPU types
 
 <Tabs>
 <Tab title="cURL">
@@ -439,7 +441,7 @@
 </Tab>
 </Tabs>
 
 ### Get GPU type details
 
 Query a specific GPU type to see pricing and availability.
 
@@ -492,7 +494,7 @@
 </Tab>
 </Tabs>
 
 ### Check GPU availability
 
 Use the `stockStatus` field to check availability before creating a Pod. Values include `High`, `Medium`, `Low`, and `None`.
 

serverless/endpoints/endpoint-configurations.mdx

@@ -1,4 +1,4 @@
 ---
 title: "Endpoint settings"
 sidebarTitle: "Endpoint settings"
 description: "Reference guide for all Serverless endpoint settings and parameters. Review configuration and operations guidance for Runpod Serverless."
@@ -17,27 +17,27 @@
 
 | Setting | Default | Description |
 |---------|---------|-------------|
 | **Active workers** | 0 | Always-on workers (eliminates cold starts) |
 | **Max workers** | 3 | Maximum concurrent workers |
 | **GPUs per worker** | 1 | GPU count per worker instance |
 | **Idle timeout** | 5s | Time before idle worker shuts down |
 | **Execution timeout** | 600s (10 min) | Max job duration |
 | **Job TTL** | 24h | Total job lifespan in system |
 | **FlashBoot** | Enabled | Faster cold starts via state retention |
 
 ## General configuration
 
 ### Endpoint name
 
 Display name for identifying your endpoint in the console. Does not affect the endpoint ID used for API requests.
 
 ### Endpoint type
 
 **Queue-based endpoints** use a built-in queueing system with guaranteed execution and automatic retries. Ideal for async tasks, batch processing, and long-running jobs. Implemented using [handler functions](/serverless/workers/handler-functions).
 
 **Load balancing endpoints** route traffic directly to workers, bypassing the queue. Designed for low-latency applications like real-time <InferenceTooltip /> or custom REST APIs. See [Load balancing endpoints](/serverless/load-balancing/overview).
 
 ### GPU configuration
 
 Determines the hardware tier for your workers. Select multiple GPU categories to create a prioritized fallback list. If your first choice is unavailable, Runpod automatically uses the next option. Selecting multiple types improves availability during high demand.
 
@@ -47,7 +47,7 @@
 
 Specify up to three GPU types in priority order when configuring an endpoint. Runpod uses this ranking to distribute workers across available GPUs, improving availability during high demand.
 
 For endpoints with five or more workers, Runpod distributes workers across your selected GPU priorities. Most workers run on your primary GPU type, with fewer assigned to secondary and tertiary selections. This reduces throttling when your primary GPU is constrained.
 
 For endpoints with fewer than five workers, all workers use the highest-priority GPU type available.
 
@@ -61,16 +61,18 @@
 
 Maximum concurrent instances your endpoint can scale to. Acts as a cost safety limit and concurrency cap. Set ~20% higher than expected max concurrency to handle traffic spikes smoothly.
 
 ### GPUs per worker
 
 Number of GPUs assigned to each worker instance. Default is 1. Generally prioritize fewer high-end GPUs over multiple lower-tier GPUs.
 
 ### Auto-scaling type
 
 **Queue delay**: Adds workers when requests wait longer than the threshold (default: 4 seconds). Best when slight delays are acceptable for higher utilization.
 
 **Request count**: More aggressive scaling based on pending + active work. Formula: `Math.ceil((requestsInQueue + requestsInProgress) / scalerValue)`. Use scaler value of 1 for max responsiveness. Recommended for LLM workloads or frequent short requests.
 
+For both scaling types, the scaler value must be a whole number of 1 or greater (default: 4). Fractional values like 0.5 are not accepted.
+
 ## Lifecycle and timeouts
 
 ### Idle timeout
@@ -80,24 +82,24 @@
 ### Idle endpoint scale-down
 
 Runpod automatically scales down endpoints that go a long time without any requests, so unused endpoints don't keep consuming your account balance. 
 * After 3 days with no requests, the endpoint's max workers is reduced to 2 and Runpod sends you an email notification. 
 * After 7 days with no requests, max workers is set to 0. 
 
 This scale-down is automatic and system-driven, and the timer is based on request activity, so any incoming request resets it.
 
 Once an endpoint has been scaled down this way, it stays at its reduced max workers until you raise the value yourself. To use the endpoint again, increase its max workers in the Runpod console. To prevent an endpoint from scaling down in the first place, make sure it continues to receive requests.
 
 ### Execution timeout
 
 Maximum duration for a single job. When exceeded, the job fails and the worker stops. Keep enabled to prevent runaway jobs. Default: 600s (10 min). Range: 5s to 7 days.
 
 Configure in **Advanced** settings, or override per-request via `executionTimeout` in the [job policy](/serverless/endpoints/send-requests#execution-policies).
 
 ### Job TTL (time-to-live)
 
 Total lifespan of a job in the system. When TTL expires, job data is deleted regardless of state (queued, running, or completed). Default: 24 hours. Range: 10s to 7 days.
 
 The timer starts at submission, not execution. If a job queues for 45 minutes with a 1-hour TTL, only 15 minutes remain for execution.
 
 <Warning>
 TTL is a hard limit. If it expires while a job is running, the job is immediately removed and status checks return 404. Set TTL to cover both expected queue time and execution time.
@@ -110,16 +112,16 @@
 | Request type | Retention | Notes |
 |--------------|-----------|-------|
 | Async (`/run`) | 30 min | Retrieve via `/status/{job_id}` |
 | Sync (`/runsync`) | 1 min | Returned in response; also available via `/status/{job_id}` |
 
 Results are permanently deleted after retention expires.
 
 ## Performance features
 
 ### FlashBoot
 
 Reduces cold starts by retaining worker state after spin-down, allowing faster "revival" than fresh boots. Most effective on endpoints with consistent traffic where workers frequently cycle between active and idle.
 Both new GPU and CPU endpoints will have FlashBoot enabled by default, and you can edit existing endpoints to enable or disable FlashBoot.
 
 ### Model
 
@@ -135,10 +137,10 @@
 
 [Network volumes](/storage/network-volumes) provide persistent storage across worker restarts. Tradeoffs: adds network latency and restricts your endpoint to the volume's data center. Use only when you need shared persistence or datasets exceeding container limits.
 
 ### CUDA version selection
 
 Ensures workers run on <MachinesTooltip /> with compatible drivers. Select your required version plus all newer versions, since CUDA is backward compatible and a wider range increases available hardware.
 
 ### Expose HTTP/TCP ports
 
 Exposes the worker's public IP and port for direct external communication. Required for persistent connections like WebSockets.