The 401 sits outside what the retry path can fix, which is what makes it terminal. QStash delivers on time; the postmortem, published on dev.to by the developer who runs the social-media scheduler PostStage, is explicit that delivery behaves exactly as documented [1][8]. What lands on the endpoint is a request whose JWT was minted when the message was enqueued, days earlier [6]. The handler calls `jose.jwtVerify()`, which checks `exp` and `nbf` with zero clock tolerance [7]. `Receiver.verify()` rejects, the endpoint answers 401, and QStash comes back three more times carrying the same token [9]. That is four attempts against one expired string [2]. Retries are built for transient faults, and an expired timestamp does not become valid on a second attempt.
The horizon where this appeared was roughly four to five days out, while one- and two-day schedules kept working normally [3][5]. Read that as a measurement of one account, not a documented limit, because the writeup never names the token's lifetime. For the number to transfer, your plan would need the same signature lifetime and your verifier would need to refuse clock skew the same way this one does.
The repair moves the far-future state out of the queue and into Postgres. A post inside `QSTASH_WINDOW_MS` is enqueued at creation; anything further out sits at status `SCHEDULED` with a null `qstashMessageId`, an ordinary resting state rather than a failure [10]. A dispatcher then sweeps for `SCHEDULED` rows due within the window and enqueues each one [11]. The default window is 24 hours, chosen because a daily cron already existed [12]. Against a failure horizon near 96 hours that leaves 72 hours of margin, so the longest any signature must survive is a quarter of the distance to where the 401s started [1]. None of this touches accuracy: the window governs only how long a signature ages before use, and QStash still fires at the scheduled second [14].
Tightening it further is where the bill arrives. The aggressive configuration points an external scheduler at a dedicated dispatch endpoint every five minutes and drops the window to about thirty minutes [13]. On free-tier Neon Postgres, that pattern consumed a month of compute allowance in days [17]. Neon autosuspends after roughly five minutes idle, and a driver on a five-minute cadence, 288 runs a day, never lets that gap open [18][3]. Autosuspend was the cost control, and the staleness fix disabled it as a side effect of closing the gap.
The two guards around the fix are the better engineering. The recovery pass looks for `QUEUED` posts well past due with zero publish-log rows, and it can trust that signal because the webhook's first action is always to write the "publishing started" row [15]. Zero rows means the handler never ran at all, which is a stronger fact than a missing side effect. The handler also claims each post atomically from `SCHEDULED` or `QUEUED` into `PUBLISHING`, so a redelivery or a recovery re-enqueue cannot publish the same post twice [16]. At-least-once delivery plus a re-enqueue sweep is precisely the combination that posts to somebody's Instagram twice.
The general form is worth keeping: a queue that signs at enqueue time has a maximum useful hold that is unrelated to its maximum documented delay [19]. If the docs are silent on when the signature is generated, enqueue time is the assumption that costs you least to be wrong about.
