Skip to main content
Last Updated: October 7, 2026

​
Using the Public API

Job Queues are not available through the portal, but you can create a Job Queue with the Job Queue API. You will also need to create your container group via the public API in order to attach a job queue to it. Ensure your container image includes the job queue worker
To keep each test round short while you get the queue working, see Cold Starts and Iterating Quickly.
📘 Job Queue Connections A Job Queue can be connected to multiple container groups at once. but a container group can only be connected to at most a single Job Queue. The connection is set when you create the container group. It cannot be added, changed or removed afterwards, so to change it you need a new container group.
We recommend adding a readiness probe to your container deployment. This probe will allow your replica to announce to the Job Queue Service when it’s ready to receive and process jobs. We recommend using it in conjunction with a startup probe. Readiness probes will start to run after a startup probe succeeds. Without a startup or readiness probe, the Job Queue Worker will immediately start to look for jobs, even if your application inside is not yet ready to receive jobs. If this happens, the job will fail and you’ll need to submit it again. In our testing, all four attempts of a waiting job were used up within seconds, and the job was marked failed permanently. With a readiness probe in place, the worker waited until the probe passed and then took the jobs with no failed attempts. How the readiness probe is configured will depend on your container image, and how it’s configured inside. Many prebuilt containers or http-apps found in open-source libraries will have a liveness API URL you can check, that will respond with a 200 code when it’s ready to receive work. Other times, any pre-requisite work may be done before the server starts, and the server starts up as the last step, so any health-check endpoint would work. In a Whisper Large v3 example below, this is what we have. If your container does not contain a way to check health statuses, you may need to add one of your own. You can usually find any references to this in the readme or documentation for the container image you are using. Readiness probes can flip between passing and failing, and will continue to check until it’s ready to go.
The portal shows “Headers: None Configured”. If you create the container group through the API, an HTTP probe must still send "headers": []. Leaving the field out is rejected with ReadinessProbe.Http.Headers: The Headers field is required.