Uploads to my cloud storage provider started failing a couple of hours ago and nothing changed on my side

The shared-credentials point is the one to act on today. I ran for a year on the tool's defaults, with occasional unexplained failures that I put down to my connection, and they stopped entirely the week I registered my own client.

One caveat worth knowing: a newly registered client is often in a testing state with restrictions, and moving it to a published state can require a review process depending on the provider and the scopes you request. For personal use you can usually stay in the restricted state — you are the only user — but read what the restrictions are, because on some providers a testing client's authorisation expires after a fixed period and your sync stops working weeks later for a completely different reason.

Set a reminder if that applies. It is a nasty one to diagnose from cold.

Almost certainly a limit, and almost certainly not one measured in gigabytes of storage. Uploads failing while downloads and listings keep working is the signature.

The limits that produce this:

1. A daily upload cap. Several providers cap how much you can upload per day, separately from how much you can store. Hit it and uploads are refused until the window rolls over, typically within twenty-four hours. Downloads are unaffected because they are metered differently or not at all. This fits your symptoms exactly and it resolves by itself, which is worth knowing before you spend the evening on it.

2. API rate limits, and this is the one that surprises people. Most sync tools ship with a default set of API credentials shared by every user of that tool. Those credentials have a quota, and it is consumed by everybody in the world using the tool that day. So your uploads can start failing because of other people's activity, with nothing at all having changed on your side.

The fix is to register your own API client with the provider and configure the tool to use it. You then have your own quota, which for a single home server is effectively unlimited. It is a form to fill in on the provider's developer console and a couple of values to paste into your configuration, and it is the single highest-value change you can make to any of these setups.

Do it even if today's problem turns out to be something else. Sharing a quota with the entire internet is a permanent source of mysterious intermittent failures.

3. A per-file or per-request limit — maximum file size, or a limit on operations per second. Failing on the same large file every time points here rather than at a daily cap.

4. Genuine account-level enforcement — a policy flag, a payment problem, a security hold. Rarer, and there is usually a notice in the account's web interface. Worth thirty seconds of looking.

How to tell which, quickly:

• Read the actual error, not the summary. Turn the verbosity up and get the provider's response body. These APIs return specific error identifiers — a rate limit, a quota exceeded, a size limit — and the tool's top-level message flattens all of them into "upload failed". The identifier names the cause outright.
• Try one tiny file by hand. If a single small upload succeeds, you are being throttled rather than blocked, and the answer is pacing. If even one small file fails, it is a cap or an account-level issue.
• Check the provider's status page, which costs nothing and occasionally is the whole answer.

Once you know, the durable fixes are: your own API credentials, a transfer rate limit so you stay under the per-second thresholds, and a backoff on retries. Aggressive retrying against a rate limit makes it worse and can extend how long you are throttled — so a tool configured to hammer a failing endpoint is actively working against you.

Add alerting on this before you fix it, because the pattern you describe — one direction failing quietly on a schedule — is the failure mode that goes unnoticed for months.

If your sync is a scheduled job, make a failed run notify you. A backup that has been silently failing since March is worse than no backup, because you believe you have one.

And separately from alerting: verify the far end has what you think it has. Check the file count and a recent file's timestamp on the remote, not just that the job reported success. The two are not the same claim.

If it does turn out to be a daily cap, consider whether the job needs to move that much data at all.

A sync that reuploads files it has already sent — because a timestamp changed, or a checksum is not being compared, or something is rewriting files in place — burns the allowance for no benefit. Look at what was actually transferred in the last few successful runs; if the volume is roughly constant and roughly the size of the whole dataset, it is not doing an incremental sync and that is the real problem.