Stripe test clock stuck in advancing: poll for ready, check internal_failure

TL;DR: # Stripe test clock stuck in advancing: poll for ready, check internal_failure ## The symptom You advance a test clock, then immediately read the subscription or wait for a webhook that never seems tied to the new time. The subscription still shows the old period, or your test asserts before Stripe finished. ## Confirm the cause Retrieve the clock and look at

Stripe test clock stuck in advancing: poll for ready, check internal_failure

The symptom

You advance a test clock, then immediately read the subscription or wait for a webhook that never seems tied to the new time. The subscription still shows the old period, or your test asserts before Stripe finished.

Confirm the cause

Retrieve the clock and look at status:

const clock = await stripe.testHelpers.testClocks.retrieve('clock_...');
console.log(clock.status); // 'advancing' | 'ready' | 'internal_failure'

advancing means Stripe is still processing. This is normal and can take seconds.

The fix

Never assert or read dependent objects until the clock is ready:

async function advanceClockAndWait(clockId, targetUnixTs) {
  await stripe.testHelpers.testClocks.advance(clockId, { frozen_time: targetUnixTs });
  for (let i = 0; i < 60; i++) {
    const c = await stripe.testHelpers.testClocks.retrieve(clockId);
    if (c.status === 'ready') return c;
    if (c.status === 'internal_failure') throw new Error('clock advancement failed');
    await new Promise(r => setTimeout(r, 2000));
  }
  throw new Error('clock never became ready');
}

Rules that bite:

• frozen_time must move forward. You cannot rewind a clock.
• Only customers and subscriptions created on the clock (via the test_clock param) follow it. A subscription on a regular customer ignores your clock entirely, which looks exactly like "the advance did nothing."
• Advancement fires real webhooks (invoice.payment_failed, customer.subscription.deleted) asynchronously. Wait for the clock and your webhook processing before asserting.
• Test clocks only exist in test mode. Guard every helper so it refuses to run against live keys.

Verify the fix

Create a clock, a customer on it, and a trial subscription. Advance past trial_end, poll to ready, and confirm the subscription flipped to active and invoice.payment_succeeded arrived. Then attach a failing card, advance past the retry window, and confirm customer.subscription.deleted fires. Total wall time should be minutes, not the 40 real days.

When to use

You hit exactly this: Stripe test clock stuck in advancing: poll for ready, check internal_failure in Stripe test clock stuck in advancing.

When not to use

A different error, or the same symptom in a different tool. This page only covers the failure above.

Compatibility

Stripe test clock stuck in advancing.

Stripe's test clocks documentation describes creating a clock with frozentime, attaching customers to it, and advancing it to simulate renewals, trial ends, and failures (docs.stripe.com/billing/testing/test-clocks). Clock advancement is asynchronous with statuses including ready and internalfailure, and only objects created on the clock follow it.