Hey — quick honest question, I’m not selling anything.
You manage n8n workflows for clients, right? When one breaks — say a client’s Google login expires and their automation silently stops — how do you currently find out? And how long does it usually take before you or the client notices?
Asking because I got burned by this exact thing last month and I’m trying to see if it’s just me or a real pattern. Would love your actual experience.
yeah, silent cred expiry is brutal, google especially. what usually happens is the oauth refresh token just quietly dies, expired, revoked, or the scopes changed, and n8n keeps marking the run “success” because the node before it didnt technically fail. so nothing alerts. it just stops producing output and everyone finds out days later when a client asks where their leads went.
the thing that actually fixed it for me wasnt monitoring the workflow, it was a separate watcher. small workflow on a schedule that pings each critical creds actual endpoint, like a cheap read call to the google api, and if it gets a 401 back it messages me before any real automation runs on stale auth. catching the dead token is easy. the part that got me was the half-finished runs, where it dies mid-loop and youve already written half the rows somewhere.
so honestly curious how you handle that side. when one silently stops for a client, are you finding out from your own logs or is it the client telling you first. thats the tell for whether its just you or the pattern.
This is exactly it — the “success but no output” thing is the worst part, because every alert system trusts that status. Your cheap-read-call watcher is smart, I’ve done a rough version of the same.
To answer your question honestly: for a while it was the client telling me first, which is the worst possible way to find out. What changed it for me was tracking each credential’s real state separately from the run status — so a dead Google token shows as “needs attention” even when n8n reports the run as fine. That flipped it from “client emails me” to “I catch it first” most of the time.
The half-finished-run problem you mentioned is the one I still don’t have clean. Right now I just detect the partial failure and re-run from a checkpoint, but it’s manual. How are you handling the already-written-half-the-rows case — do you make your loops idempotent, or clean up and re-run from scratch?
Genuinely the most useful exchange I’ve had on this. Mind if I message you directly? I’m building something small around exactly this “whose fault + did the client notice” problem and I’d love your eyes on it.
yeah man message me for sure, this format’s not great for going deep on it anyway. and to answer the loop question, i lean idempotent over cleanup. if every row you write is keyed on something stable from the source, a re-run just overwrites the same rows instead of duplicating, so a half finished run and a full re-run land in the exact same place. cleanup and re-run from scratch works too but now you’re maintaining delete logic that has to know exactly what the partial run touched, and that’s the part that rots. make the write idempotent and the partial failure basically stops being a special case. happy to get into the whose-fault-did-the-client-notice part properly once you message me, that’s the fun bit.