Moises Upload Stuck or Usage Limit Reached: A Triage Guide
Triage a stuck Moises upload or account usage limit: preserve the source, isolate file and network causes, check current account terms, and choose a local fallback.
An upload that never finishes and an account usage limit can look like the same blocked workflow, but they have different remedies. Do not repeatedly convert or re-upload the only copy of a rehearsal recording. Preserve the source, identify the boundary, and decide whether waiting for a hosted workflow still makes sense.
Direct answer: read the exact status first. A rejected file, stalled transfer, processing queue, authentication failure, and account limit are different incidents. Preserve the source, test a small known-good file, record the client and status, and check current Moises account terms. If the upload dependency itself blocks rehearsal, build a separate local Session Craft project; do not claim that local and hosted outputs are identical.
First identify the boundary
- The file is rejected before transfer: verify the currently supported container, codec, duration, and file-size rules in Moises documentation.
- Progress begins and then stops: test a stable connection and a small known-good file to separate network behavior from source-file behavior.
- The upload finishes but processing never completes: retain the project identifier and status evidence for service support.
- The account reports a limit: read the current plan allocation inside the service; limits and access terms can change.
Avoid claims based on an old monthly quota or price screenshot. The useful fact is the status your account reports now.
Preserve a diagnostic record
Record the source format, duration, size, application surface, timestamp, visible status, and whether the same file succeeds elsewhere. Do not publish the audio, account token, or a signed upload URL.
If a smaller file works on the same connection, inspect the original container and duration. If no file works, move outward to account, client, or service status. If the browser works but the desktop client does not, compare versions and authentication state rather than blaming the song.
Use a local fallback when upload is the wrong dependency
Session Craft runs its bundled separation model on the desktop. There is no upload queue or hosted usage counter in the local separation path; processing time depends on the machine and source. The Community edition is free.
A safe fallback sequence is:
- Keep the original source unchanged.
- Open the file locally in Session Craft.
- Run separation and inspect the stems on the difficult passage.
- Set the A/B loop, speed, pitch, and mixer state needed for practice.
- Save the project and reopen it before relying on the session.
Do not assume local output is identical to Moises. The services do not publish evidence that they use the same model. If sound quality decides the choice, follow the reproducible stem comparison.
Choose the lasting workflow
A hosted service remains useful when its mobile, account, and cross-device workflow matter more than the upload dependency. A local desktop workflow is useful when the source must remain on the computer, practice must continue offline, or repeated songs should not pass through a remote queue.
Download Session Craft Community and test the blocked song locally without changing the original file.
Upload incident decision table
| Visible symptom | Boundary to test | Do not do |
|---|---|---|
| File cannot be selected or is rejected | Current format, codec, size, and duration support | Rename an unsupported file extension and assume conversion happened |
| Upload stays at the beginning | Client access, authentication, network, and source readability | Repeatedly submit the only copy |
| Transfer advances then stalls | Connection stability, client, and larger-file behavior | Publish signed URLs, tokens, or private audio as evidence |
| Upload completes but separation waits | Service processing state and project identifier | Re-encode repeatedly before preserving the status |
| Usage or processing limit appears | Current account allocation and tier | Quote an old blog limit as current |
| Browser succeeds, desktop fails | Version, login state, permissions, and client-specific path | Blame the recording before comparing the same source |
| One file fails, known-good file works | Container, codec, duration, or source corruption | Convert destructively over the original |
Make a copy for any diagnostic conversion. Preserve the original bytes and record which copy was tested.
Capture useful evidence
Keep:
- date, time, and time zone;
- web, desktop, or mobile surface;
- application or browser version;
- operating system;
- account tier as displayed at the time;
- source container, codec, duration, and size;
- visible error text or processing state;
- project or job identifier;
- whether a small known-good file succeeds;
- whether another network changes the result.
Redact email addresses, account identifiers, tokens, signed URLs, and private filenames before sharing screenshots.
Check account limits without guessing
Moises’ official documentation describes different free and paid capabilities, processing allocations, separation options, chord limits, speed/key limits, and export formats. Those details can change. The account surface and current official help are the source of truth for the affected user.
An account limit is not a transport failure. Retrying the same upload will not create new entitlement. Decide whether to wait, change the current plan, use an authorized existing output, or move this practice job to a local workflow.
Check the file without destroying it
A media file can have a familiar extension while containing an unexpected codec or damaged index. Inspect it with a trusted local tool, then create a diagnostic copy in a currently supported format if needed.
Keep:
original/
rehearsal-take-original.ext
diagnostic/
rehearsal-take-test-copy.wav
notes/
upload-incident-2026-07-30.txt
If the test copy works, the result points toward the original container or codec path. It does not prove that every file in that format fails.
When a local fallback is the correct architectural fix
Use Session Craft when the recurring requirements are:
- no upload dependency;
- local work with private rehearsal or lesson audio;
- six-stem practice mixes;
- speed and pitch control;
- A/B loops;
- saved project continuity;
- offline repetition.
Community currently includes all of those. Professional adds chord detection and backing-track export.
Local does not mean instant. Separation time depends on source and hardware. It also does not mean perfect: the six-role model can bleed or misassign material. Compare the blocked song’s difficult passage with the full source and any lawful hosted result.
Local fallback procedure
- Copy the source into an owned session folder.
- Import it without altering the original.
- Run six-stem separation.
- Inspect Vocals, Drums, Bass, Guitar, Keyboard, and Other.
- Build the required practice mix.
- Set A/B around pickup and resolution.
- Set speed and pitch separately.
- Save the project.
- Close and reopen it.
- Export with Professional only if a portable file is required and authorized.
If stem files later move or disappear, restore their paths or backup before resaving the only project. The current application can fall back to the available full mix while retaining missing-stem references for recovery.
Compare hosted and local results fairly
Use the same source and exact passage. Match output loudness. Check:
| Evidence | Question |
|---|---|
| Bleed | Which unwanted role remains? |
| Missing material | Which desired note or transient disappeared? |
| Timing | Did drum or pick attacks smear? |
| Pitch/timbre | Did sustained notes become unstable? |
| Context | Does the reconstructed practice mix preserve form? |
| Continuity | Can the session reopen tomorrow? |
The Demucs versus Moises stem comparison gives a reproducible listening method. It does not claim that similar model names prove identical processing.
Keep Moises when its workflow still fits
Moises can remain the right choice when cross-device account access, setlists, and its broader web/mobile/desktop practice suite matter. A temporary incident does not invalidate the product category.
Use Session Craft as a complementary local route if some sensitive or urgent songs should avoid the upload queue. It is reasonable to keep both and assign each a documented job.
Incident QA checklist
- Original source remains unchanged.
- Exact visible status is recorded.
- Current account terms are checked.
- A small known-good file separates account/network from source behavior.
- Browser and desktop state are compared when relevant.
- Diagnostic conversions use copies.
- Private evidence is redacted.
- Local fallback stem quality is checked on critical passages.
- Session Craft project survives restart.
- Any export is authorized and reopens correctly.
Frequently asked questions
Why is my Moises upload stuck?
Possible boundaries include source support, local file access, authentication, network transfer, client behavior, service processing, or account entitlement. The visible stage and a known-good comparison narrow the cause.
Does an upload limit mean the service is broken?
No. A reported allocation is an account state. Read the current terms shown for the account and decide whether to wait, change plan, reuse an authorized result, or move the job locally.
Can I use Session Craft without uploading?
Yes. Its practice source, six-stem separation, playback, speed, pitch, loops, and project save are local.
Is local separation free?
Session Craft Community currently includes local six-stem separation. Professional is needed for chord detection and backing-track export.
Will Session Craft produce the same stems as Moises?
Do not assume that. Models, weights, separation layouts, inference settings, and post-processing can differ. Compare the exact source at matched level.
Should I delete the Moises project after moving?
Not until the local project, source paths, stems, loop, and any required export pass restart and recovery tests. Keep only data you are authorized to retain, following the relevant account and recording requirements.
Final recommendation
Treat “upload stuck” as an incident with a specific boundary, not a reason for random retries. Preserve evidence and the original source. If the recurring dependency is wrong for private or time-sensitive practice, use a verified local Session Craft project and keep the hosted route only where its cross-device benefits matter.
Incident record for a stuck upload
Record the local time, client and version, account state shown, source format and duration, visible stage, exact error text, and whether a small known-good file behaves differently. Do not place private audio, credentials, or unnecessary personal information in a support screenshot.
If the failure is an account limit, current account information controls the remedy. If it is a transfer or processing failure, preserve the source and avoid repeated conversions that make comparison harder. A local fallback should use the original lawful file, not an increasingly compressed retry copy.
After building the local Session Craft project, close and reopen it before treating the fallback as ready. Keep the hosted project until required data and authorized outputs are recovered, then apply the relevant retention and deletion policy.
<!-- multilingual-related-reading:start -->Related guides
Continue with the same-language pages below. They cover adjacent stages without changing the canonical owner of this topic:
<!-- multilingual-related-reading:end -->