We generated 413 articles while our status board said posting had stopped

What we hit

Our status board said posting to note.com had been at 0 since 2026-07-10 and that we needed to log in again. That was a correct description of the visible result. Nothing was being published, and the session needed attention.

We read it as a stopped posting pipeline. The distinction seemed small until we inspected the logs. A pipeline that never starts and a pipeline that completes its expensive work before failing can leave the same empty publication history. Our status board described that history without telling us which kind of failure we had.

What we found was the latter. From 2026-07-10 to 2026-09-12, the pipeline had generated articles and failed to publish them 413 times. There were no successful posting logs.

What we assumed

The mistake was treating an absence of output as evidence of an absence of activity. We knew we needed to restore the login, but we had misunderstood what the system was doing while it waited for us.

The logs showed cron running normally, 9 times a day. Topic selection succeeded every time. Article generation, using a command-line tool and web search, also succeeded every time. Only the final posting step failed, returning not_login.

That changed our understanding of the incident. We had spent 2 months generating 9 articles a day and throwing them away. The scheduled work had continued through topic selection and generation even though the session could no longer support the operation those stages existed to prepare.

The status board was therefore right about the required intervention and wrong as an explanation of the system. Logging in again was necessary. Understanding where the failure happened was necessary too, because restoring the session alone would leave the same waste possible the next time it became invalid.

Why the session looked alive

The session cookie had an expiry of 2026-10-02. That date was still in the future, so the stored session appeared usable if we judged it by its expiry.

But current_user returned 401. The session had been invalidated server-side. The future expiry did not mean the server still accepted it, and looking at the cookie could not establish whether we were currently authenticated.

Our existing liveness check provided another misleading signal. It loaded the top page and checked that the resulting URL did not contain /login. That check assumed a logged-out visitor would be redirected to a login page.

note.com serves its top page to logged-out visitors too. The URL test therefore passed without demonstrating that the session worked. It checked a page that was available regardless of the authentication state we needed to establish.

Together, these checks let us proceed on evidence that did not answer the relevant question. The cookie had time remaining, and the top page was accessible. Neither fact established that the server recognized our session. We discovered the failed authentication only when the posting API returned not_login, after generation had already finished.

The fix was a check before generation

We added a login check that called current_user and placed it at the start of the posting script, before article generation.

The condition for continuing was explicit: the response had to be 200 and include the urlname field. Anything else caused the script to stop without generating any article text.

This moved the authentication decision to the point where it could prevent wasted work. Previously, we learned that the session was unusable through a failed attempt to publish a completed article. With the new check, we asked the server about the session before committing to generation.

We also made the unavailable-session outcome a logged skip with exit 0. The purpose was to avoid filling cron with error notifications while still recording why the run did not proceed. A scheduled invocation could finish without generating an article when the required authentication was unavailable.

We ran the changed script and verified that it stopped before entering generation. That verification covered the immediate failure we needed to prevent: continuing to produce articles with an invalid session.

Restoring the login had its own obstacle

When we then tried to log in again, the automation browser was rejected with “browser may not be secure.”

The bundled browser was rejected, and selecting channel: "chrome" did not resolve it. In this setup, that selection also pointed to a bundled testing browser, so it encountered the same rejection.

The way through was to use the real installed browser binary with a dedicated persistent profile. Restoring access addressed the invalid session; the earlier change addressed what the pipeline would do whenever authentication was unavailable.

The lesson

When we see output at 0, we need to check whether the work leading to it also stopped. We should test a prerequisite before expensive processing when its failure can already be detected. A cookie expiry and an accessible public page do not establish that a session is alive. We need a check that asks the server for something requiring the authentication we intend to use.

Root Cause is written by TechAthletes. We run the agents behind pipelines like this side by side in Agent Tile, our macOS app for keeping many Claude Code sessions in view at once.