To check it, I had to publish
I built a pipeline that uploads videos to a brand channel automatically. OAuth gets a token, the token calls upload. Ordinary shape.
The problem was that there was no way to ask "is this token alive right now?" The pipeline had exactly one path — upload — and the only moment I learned whether auth was valid was the moment an upload succeeded or failed. Checking state and performing an irreversible public act shared a code path.
Worse, the only way to learn which channel was connected was also the upload result. An account can have more than one channel, and a re-auth can land on a different one. To find out, you upload again.
Does your pipeline have a path that changes nothing and only answers "who am I logged in as right now?"
What happens when checking is executing
If checking is executing, checking gets expensive. Expensive means you do it less. Doing it less means the token dies at some unknown point and you find out on the day you actually need to ship.
Check often instead and you accumulate test garbage on the channel. You can work around it by uploading privately and deleting, but that still burns upload quota and touches the channel's history. Either way you lose.
At this point I had finished channel setup and had five public uploads live. I decided to hold further uploads until the redesign deploy was done. Auth still has to stay alive during a period when I'm deliberately not uploading. That is exactly the situation where you must verify without publishing.
What would you do? For the weeks where uploads are paused, how would you confirm the token still works?
Two small pieces, split out
First, auth_check.py. Twenty-two lines. It runs the OAuth re-auth and queries the connected channel, then prints it. It never calls upload. Running it answers two things: is auth valid, and which channel am I attached to. That's all it does.
Second, reach_report.py. Thirty-eight lines. It reads views, likes, and comments for recent uploads through the Data API and prints a pulse. No writes here either. Read only.
The reason they are two files is simple. One asks whether the door opens; the other asks what's inside. Merged, an empty report is ambiguous — broken auth or genuinely no data. Split, a failure in the first one means you don't need to look at the second.
Sixty lines total. I didn't touch the pipeline itself and added no new dependency. Both reuse the auth and API client the upload code already had.
Self-diagnosis checklist
- Does your automation have a way to ask "is auth alive?" other than performing the real operation?
- After a re-auth, can you confirm which account and which channel you landed on before producing any artifact?
- Are the read-only diagnostic path and the write path separated in code?
The honest part
These two scripts are fresh. I have not yet seen what auth_check.py prints at the moment a token genuinely expires, because I have never waited for one to expire. So I can't claim it reports failure accurately — only that success can now be confirmed without uploading.
I haven't used the numbers from reach_report.py to decide anything either. There are only five public uploads, and more are deferred until after the redesign deploy. At that sample size a pulse is just a pulse; it says nothing about which content works. That judgment belongs to a point after uploads resume.