Email type "Expired Subscription" is not being sent

[erikgeurts]

Describe the bug

In one of my stores using WooCommerce Subscriptions, I have enabled two email types:

• Cancelled Subscription
• Expired Subscription

Both are supposed to be sent to the store manager.

What happens is:

• When a customer cancels their subscription, the corresponding email gets sent just fine
• At the date and time the subscription expires, the "Expired Subscription" email is not being sent.

We want to use these expiration notification emails to ensure that we cancel the service being provided to the former subscriber.

To Reproduce

See above.

Expected behavior

I would expect that the store manager receives the notification email at the date and time the subscription expires.

Actual behavior

The email notification mentioned does not get sent.

Product impact

WooCommerce Subscriptions

• Does this issue affect WooCommerce Subscriptions? yes/no/tbc, add issue ref
• Does this issue affect WooCommerce Payments? yes/no/tbc, add issue ref

Additional context

n/a, nothing gets logged because nothing happens

[barryhughes]

Thanks for reporting this, @erikgeurts. So far, I'm unable to replicate:

• I created a subscription product and populated the stop renewing after field, and then made a test purchase.
• Via the Tools ‣ Scheduled Actions screen, I could see that the woocommerce_scheduled_subscription_expiration action had been scheduled for that newly created subscription.
• I manually ran the action, and the subscription expired email was dispatched.

So it seems like this is functioning correctly, though clearly something isn't working well in your case. Some things I'd like to check on next:

• If you visit Tools ‣ Scheduled Actions and search for woocommerce_scheduled_subscription_expiration, can you identify a scheduled action referencing the relevant subscription ID(s)?
• Are the relevant actions present?
• Have any failed (if so, is there any useful information in the log column)?
• If they haven't failed, what is their status?

There are various possibilities here. For instance, an unexpected error condition may have stopped the scheduled action(s) from completing. Or, they may still be pending (it may be that you have a backlog of scheduled actions waiting to be processed, due to some other issue).

Let me know what you find out, and we can think about next steps :-)

[erikgeurts]

Thanks for your response and detailed investigation.

Our scenario is slightly different, in the sense that we have a model where subscriptions never expire automatically, and the renewals are all synchronized on the 1st day of the new month. We only use automatic renewals, never any manual renewals. We don't have free trial periods.

When a subscriber cancels their subscription, it remains valid but pending cancellation for the remainder of the month and then the subscription expires and our SaaS service ends on the first of the new month (when the subscription would otherwise have been renewed).

It just so happens that a customer cancelled a few hours ago, so with an expiration date of February 1st. When I look at the scheduled actions for this particular subscription, I see only two actions:

• woocommerce_scheduled_subscription_customer_notification_renewal - 5 days ahead of the renewal date (as per my settings) - this notification was not sent because we have this notification type disabled
• woocommerce_scheduled_subscription_end_of_prepaid_term - on the expiration date February 1st.

This particular customer happens to have subscribed and cancelled in January 2025, and they paid a prorated amount for the remaining days in January. Other subscriptions that are pending cancellation yet were created much earlier also have an associated woocommerce_scheduled_subscription_end_of_prepaid_term action scheduled. I've always felt this is a slightly weird term, although in some sense it is a 'prepaid term'.

There is no "woocommerce_scheduled_subscription_expiration" action for this subscription, nor for any of the other subscriptions that are pending cancellation.

It seems that your use of "stop renewing after" for the subscription product is the differentiating element. We don't use that, instead we let customers cancel their own subscriptions if they no longer need our service.

[barryhughes]

OK, apologies for misunderstanding first time round (on re-reading your initial post, the situation is quite clear). I can definitely see the utility of sending the expired subscription email in this scenario 👍🏼

[erikgeurts]

Thanks for confirming. I'd say the "needs feedback" label can be removed now :)

What might happen next? Are you investigating if this is an actual bug or perhaps just a bit of missed functionality?

[barryhughes]

I'd say the "needs feedback" label can be removed now :)

Yep, it can be removed (in case it's useful to know this, though, it's not exclusively there because of a need for feedback from the report author—it can also serve as a reminder for the assignee or triager to solicit input from the team, which I've now done).

What might happen next?

We'll work on it in due course :-)

Our current thought is that we should send the cancelled subscription email, which in fact is already used when a subscription transitions directly to cancelled.

That doesn't happen in this scenario, though, because the subscription status initially changes to pending cancel and the email is instead dispatched at that point (we have a control in place to prevent that same email being dispatched a second time for the same subscription ... so, when the status is ultimately set to cancelled, it is not sent again). However, we can introduce one or more additional settings to offer better control over this aspect.

[erikgeurts]

No, I don't think sending the "subscription cancelled" email is a good idea. This is already sent the very second a customer cancels manually, which could be weeks before the expiration date. Receiving this email means we have a customer success manager evaluate the case and perhaps contact the customer to see if they're willing to reactivate or subscribe to some other service.

Keep in mind that the act of cancelling sets the subscription to "pending cancellation" and only on the actual expiration date the subscription actually ends completely. I would call that "expired" but the software calls it "cancelled".

When the actual expiration occurs, we definitely want to receive the actual and separate "subscription expired" email so that we can set the wheels in motion to terminate the service we provided to the customer. We have the capability to process such incoming emails (just like with a new subscription) and automatically act on that.

Coming back to the remark about not sending "subscription cancelled" more than once: this is, in my eyes, not the correct approach. We've had cases where a customer cancels, reconsiders, and then weeks or months later cancels again, and we didn't get alerted about it. I consider that to be a flawed approach.

[barryhughes]

When the actual expiration occurs, we definitely want to receive the actual and separate "subscription expired" email so that we can set the wheels in motion to terminate the service we provided to the customer.

Understood, though it's worth noting that nothing about what I outlined stops us from making the subscription status (pending-cancel vs cancelled) clear to the recipient. In other words, the existing template used for the cancellation email may not stay exactly the same.

Coming back to the remark about not sending "subscription cancelled" more than once: this is, in my eyes, not the correct approach. We've had cases where a customer cancels, reconsiders, and then weeks or months later cancels again, and we didn't get alerted about it.

Indeed ... if it is reactivated, then the 'flag' which indicates the cancellation email was already sent ought to be cleared. I'll check to see if we have an existing bug report for this.

[erikgeurts]

Indeed ... if it is reactivated, then the 'flag' which indicates the cancellation email was already sent ought to be cleared. I'll check to see if we have an existing bug report for this.

I have, at some point in the past, had a support ticket about that, but I don't remember when. It was not reported here on Github as far as I know.

[erikgeurts]

Indeed ... if it is reactivated, then the 'flag' which indicates the cancellation email was already sent ought to be cleared. I'll check to see if we have an existing bug report for this.

I have, at some point in the past, had a support ticket about that, but I don't remember when. It was not reported here on Github as far as I know.

I found a closed issue about this particular matter, #658 and the associated PRs #681 and #686 so this appears to have been fixed some time ago, we just haven't had any specific cases of customers cancelling, reactivating and cancelling again it seems.

The thing that we sorely miss, though, is an email that gets set to the store manager when the customer re-activates the subscription. Sometimes we see a customer cancelling, and then reactivating a few minutes later, and it would be good to know about that sort of sequence.