YouTube uploadLimitExceeded vs quotaExceeded: which limit hit?

If a Short upload fails and the error says quotaExceeded, your Google Cloud project ran out of API quota. If it says uploadLimitExceeded, the channel hit its own daily video upload limit, which YouTube describes as a platform restriction that is separate from your project's quota. They need different fixes, so log the error reason, not just the HTTP status.

Both come from YouTube's error reference (read 2026-10-02), and the quota side from the videos.insert page (read 2026-10-02).

What each error means

The error reference lists the three upload-adjacent errors below. The wording in the table is paraphrased from that page.

Why the status code alone misleads

One of the two quota-style failures is a 403 and the other is a 400, but the reliable signal is the error detail string in the response body. Branch on that string. A retry loop that treats every failed upload as "try again later" will keep spending calls against the same wall.

The videos.insert page says the method costs 100 calls per day, at 1 unit per call, in the Video Uploads bucket. That is a project-level counter. A channel-level upload limit is a different counter: the error page calls it separate from your project's API quota, so a quota increase is not described as a fix for it.

A handling rule for a batch

• On quotaExceeded: stop the queue, keep the remaining files, and resume after the daily quota resets. See the quota reset time.
• On uploadLimitExceeded: stop uploading to that channel and surface it to a person. The page gives no reset time in the text I read, so do not hard-code one.
• On rateLimitExceeded: slow down and retry the same item.
• Record the error detail next to the file name so the next run starts from the right item.

Where Sume fits

Sume makes the video files; it does not upload to YouTube, and the Sume docs describe no YouTube upload endpoint. A bulk Format run queues up to 100 ordinary Format runs with a concurrency window, so you can render a batch overnight and then drain it into YouTube at whatever pace the two limits above allow.

Keeping production and upload as two separate queues is the useful part. A failed upload then never forces you to re-render, because the finished files are still waiting.

Why this split is worth the effort

A batch uploader that handles both errors the same way tends to fail in one of two ways. Either it stops early on a recoverable rate error, leaving Shorts unpublished for no reason, or it keeps hammering a channel that has already hit its limit. Neither costs money, but both cost a day of your release calendar.

The fix is small: a three-way branch on the error detail, a persisted queue, and a log line per item. Add a manual review step for uploadLimitExceeded, because only a person can decide whether to wait a day or move the remaining videos to another publishing plan.