Introducing job queues in Chunkify

Queue jobs when your team reaches its vCPU limit

Jobs continue to run in parallel within your team's vCPU limit. Previously, reaching that limit meant new job requests returned HTTP 429. Now those jobs enter a queue, provided there is room in your plan's queue allowance.

Waiting jobs start automatically, oldest first across your team's projects, as enough vCPU capacity becomes available. You can cancel a pending job before encoding begins.

New jobs initially report pending through the API while awaiting scheduling, even when vCPU capacity is available. An accepted create-job response looks like this, with other fields omitted:

{
  "status": "success",
  "data": {
    "id": "job_example",
    "status": "pending"
  }
}

The vCPU limit controls how much work can run in parallel; your plan also limits how many jobs can wait. A full queue still returns HTTP 429. Submit again once a pending job starts or is cancelled.

Deliver files through your own CDN

Keep encoded videos under a shared folder in your AWS S3 or Cloudflare R2 bucket and serve them through your own CDN.

Set an output base prefix such as media/, then use relative paths for your jobs. A job path of exports/video.mp4 becomes media/exports/video.mp4.

Storage setup with sample values.

Configure the folder and CDN with the TypeScript SDK:

import Chunkify from '@chunkify/chunkify';

const client = new Chunkify({
  projectAccessToken: process.env.CHUNKIFY_TOKEN,
});

await client.storages.update('strg_example', {
  base_prefix: 'media/',
  cdn_base_url: 'https://media.example.com',
});

With a CDN configured, output files include a stable cdn_url in API responses and completed-job webhooks. You configure and manage the CDN.

Here is a job.completed webhook excerpt using those settings. Other job and file fields are omitted, and the download signature is a placeholder:

{
  "id": "notf_example",
  "event": "job.completed",
  "date": "2026-09-07T12:00:00Z",
  "data": {
    "job": {
      "id": "job_example",
      "status": "completed"
    },
    "files": [
      {
        "id": "file_example",
        "path": "media/exports/video.mp4",
        "url": "https://storage.example.com/media/exports/video.mp4?signature=EXAMPLE",
        "cdn_url": "https://media.example.com/media/exports/video.mp4"
      }
    ]
  }
}

The new data.files[].cdn_url is an additional field. The existing data.files[].url remains a temporary download link. CDN URLs are unsigned and omitted when no CDN is configured; your application must handle authentication for a private CDN.

Changing the prefix affects outputs that have not uploaded yet. Existing files stay where they are. Set base_prefix to "" to use the bucket root, or cdn_base_url to null to remove the CDN setting.

See your team's compute usage

Open Usage beside your avatar to check your team's vCPU usage, pending jobs, included compute, and billing dates. Team owners can also view their wallet and add funds.

Automatic transcoder setup keeps the configuration calculated for your media, capped by your plan's CPU limit. Manual setup offers the CPU types and quantities supported by your plan and video duration, adjusting the quantity when you choose a larger transcoder.

Fixes and alerts

• Fixed delays that could leave pending jobs waiting after capacity became available.
• Maximum-CPU alert emails have been removed. CPU plan limits still apply.

Compute warnings account for wallet funds

Exhausting your included compute no longer triggers a compute warning while your wallet has funds. The panel explains that processing continues using your balance. A red compute warning appears when both are exhausted.

Screenshots use sample data.

For setup details, read the storage guide and completed-job webhook reference.