Things break.
Nothing gets lost.
Clouds go down, tokens expire, mail servers time out. None of that should mean a document quietly disappears — so a document is never simply “done or failed”, it moves through states, and every failure has a defined way back.
Four states, and a way out of each.
Every document carries a status. It's visible in your History, and it's the same status the system itself uses to decide what to do next.
The attachment has been saved and is queued to be read. It gets here within seconds of the email being seen.
The document is being read and matched against your rules.
A rule matched, and the file is being written to your cloud folder.
The file is in your folder. It appears in your History with the rule that matched and the exact destination.
A document that matches no rule doesn't enter this ladder as a failure — it's kept with the reason, which is normal operation rather than something to recover from.
Not every failure deserves a retry.
This is the part that's easy to get wrong, and getting it wrong is worse than not retrying at all.
Permanent — needs you
A revoked app password. A disconnected account. A credential that no longer decrypts. Retrying these every five minutes forever would repeat the same failure until the end of time and fix nothing.
The connection is flagged and you're told. No further attempts.
Temporary — retried
A mail server that didn't answer in time. A cloud with a bad minute. A network blip. These succeed on their own if you simply ask again a bit later.
Left alone and picked up on the next pass, automatically.
Without that split, a password you revoked on purpose would be hammered against your mail provider every five minutes indefinitely — which is both useless and the kind of thing that gets an IP blocked.
One broken thing doesn't take the rest with it.
A bad attachment
If one attachment in an email is corrupt or unreadable, it's recorded as failed on its own. The other attachments in the same email are processed normally — one bad PDF doesn't cost you the three good ones next to it.
An extra cloud copy
On Business, a rule can file to several clouds at once. If the second cloud fails, the main archive still succeeds; the failed copy is recorded against the document with its error and shows in your History.
An unreadable message
If a message can't be parsed at all, it's marked and the mailbox moves on. It isn't retried forever, because retrying an unreadable email just blocks every message behind it.
Retrying must never mean archiving twice.
Every message carries a key built from your account, the mailbox address, and the message's own identifier. Before anything is archived, that key is claimed. If it already exists, the message has been handled and is skipped.
That guarantee is what makes aggressive retrying safe: a sweep can pick a document back up as often as it likes without any risk of a second copy appearing in your folder.
It's also been wrong once, which is why it's worth spelling out. The key originally included the connection's internal id — which changes every time you disconnect and reconnect the same mailbox. Reconnecting therefore produced brand-new keys for messages already archived, and re-filed the whole window. It's now keyed on the account and the mailbox address, which survive reconnection.
You only hear about real failures.
Findest used to email about three things: a failed archive, a document with no matching rule, and hitting a plan limit. Two of those are normal operation and visible in your History, and sending mail about them trained people to ignore the mail.
Now only a genuine archiving failure sends an email. Security events — a new sign-in, a password change, a newly connected account — are separate, and you can turn those off in Settings.
Questions people actually ask
How quickly is a stuck document picked back up?
The sweep runs every minute, so within about a minute of stalling.
Will I end up with two copies of the same file?
No. Each message claims a key before anything is archived, so a retry of an already-archived message does nothing.
What happens if my cloud storage is full?
The upload fails and the document is marked failed with the provider's error, so it says the drive is full rather than something vague. Free up space and the document can be filed.
Does a failed extra cloud copy break the main one?
No. The main destination is archived independently; the failed copy is recorded against the document with its error.
What if I revoked the app password on purpose?
The connection is flagged after the first authentication failure and left alone. Reconnect it when you're ready and polling resumes.
Set it up once and stop checking.
That's the whole point of the recovery behaviour on this page — you shouldn't have to watch it.