For -1021, investigate timestamp acceptance. For -1022, investigate signing inputs and matching credentials. Broader account permissions do not replace either diagnosis.
Get the upstream category
A generic connection-failed banner can hide several different errors. Obtain the non-sensitive code, occurrence time, application version and intended function. A managed provider should supply a redacted upstream category before asking you to change account settings. Retain the timezone in your notes: subtracting a local display time from an unrelated server timestamp can manufacture a misleading discrepancy.
Check the executing process
Your laptop clock can be correct while the cloud worker clock is wrong. Identify the machine generating the request timestamp and have its maintainer inspect time synchronization. Also examine queues. A request constructed when a job enters a queue can already be old when sent. Correcting the system clock alone will not solve that design issue; inspect when the timestamp is actually produced.
Use the window deliberately
The REST reference defines recvWindow in milliseconds, with a default of 5000 and maximum of 60000. It controls validity, not every form of network failure. Review units and observed latency before changing it. A larger value is not a universal solution to an ahead-of-server clock. Copying a large number from an old example into every configuration can conceal the real timing problem.
Compare the signing input
Treat the parameters being signed and the parameters actually transmitted as separate objects to compare. Encoding, whitespace, line breaks or later concatenation can change the bytes between these points. You do not need to paste a real request into an online signature calculator. Ask the maintainer for a minimal reproduction with invented data in a controlled environment, checked against current official examples.
Check the credential pair
After a key change, verify that the identifier still matches its intended secret or private key. Similar filenames, stale environment variables and an unreloaded process are possible investigation points, not established diagnoses. Selecting a different algorithm name cannot substitute for its implementation. A provider lacking support for the chosen key type does not gain that support when you enable additional account permissions.
Change one thing at a time
Suppose a read initially returns a timing error, then returns a signature error after a clock correction. The new category is evidence and does not automatically invalidate the first fix. Record each change, fresh attempt and response. Do not simultaneously replace the network, key and permission set. Also confirm that the application made a new attempt rather than redisplaying its last cached failure.
Send a useful redacted report
Include the function, environment, version, UTC time range, code and recent upgrades. Algorithm names and timestamp units can be described without including credentials. Exclude secrets, private keys, complete signatures and account response bodies. If support requests deeper logs, establish the necessary fields, redaction method, private transfer channel and handling of the material after the investigation ends.
Close the specific failure
Make a fresh read after the repair and verify new data with a reasonable time label. Recheck the original trigger where practical: a failure after sleep recovery calls for examining that recovery path. One success does not cover every operating condition. Avoid repeated high-frequency probes merely to feel confident. Record a verifiable implementation or configuration cause rather than a vague claim that the exchange is unreliable.
Map the request lifecycle
Track job creation, parameter generation, signing, queue entry, actual transmission and response arrival as distinct events. A long wait in the interface may occur before the request exists, or an already signed request may age inside a queue. Those cases need different investigation. Also document where configuration comes from: changing a visible file may do nothing if the process uses a different source with higher priority. For managed tools, these are provider responsibilities. Ask for evidence and an explanation rather than repeatedly changing account permissions you cannot connect to the observed failure.