Last March, GitHub sent me a renewal email. It looked like every other receipt: one line item, a new amount, a "View subscription" button. My GitHub Pro plan was renewing at $6 per month instead of $4.
That's the entire announcement. No pricing page update, no banner, no "changes to your plan" email with a clear subject line. A one-line diff inside an email formatted exactly like the twelve before it.
I didn't notice until two months later, on a bank statement. Twelve months of that increase is $24 — trivial alone. But GitHub wasn't the only vendor doing it. Three other services had similar bumps buried the same way, and together they added up to nearly $100 a year I never budgeted.
Why vendors bury price increases in renewal emails
Renewal-email increases are not an accident of formatting. They're the lowest-friction way to raise prices: no public pricing page change to explain, no announcement to publish, and a captive audience that has already demonstrated it pays. Most customers, like me, either accept the charge without reading or miss the diff entirely. The few who notice and complain get grandfathered back — the increase only needs to survive contact with the majority who don't.
I don't think this is evil. It's rational pricing behavior in a market where switching costs are high and attention is scarce. But it changes where the audit burden falls: onto the customer, every single cycle.
The manual defense (what I did for years)
After the GitHub surprise, my system was: a spreadsheet of every subscription, a Google Calendar reminder for each renewal date, and a monthly statement review.
It worked for a while. Then it failed in the most predictable way possible — I snoozed the calendar reminder for a niche video-editing tool I had already decided to cancel, the annual charge went through in July, and I spent three days emailing support to get it back. The spreadsheet said "Cancel". The calendar said "Renewal". Neither system had the authority to act, and I was the single point of failure between them.
The structural fix: read the renewal emails like a machine
This is one of the core reasons I built SaaSClerk (saasclerk.app). It connects to your mailbox read-only — OAuth, no email content stored, AES-256 encrypted tokens — and does two things a human consistently fails at:
- It never misses a renewal email. Every message matching billing patterns gets parsed for the service, amount, interval, and next renewal date. There is no "busy Tuesday" version of this; the scan runs the same way every time.
- It reads for change, not just amount. Phrases like "will increase", "new price", or "effective" next to a number get flagged. Old and new prices sit side by side, and anything moving more than 5% lands in the review queue automatically.
The average first-week scan surfaces $4,200 in annual spend the account owner didn't know they had. Some of that is forgotten subscriptions; a meaningful slice of it is exactly this — increases nobody approved because nobody saw them.
What to do this week
One hour, three steps:
- Search your mailbox for
subject:(renewal OR invoice OR receipt)over the last 12 months, and check every "new amount" against what you thought you were paying. - Cancel anything you can't remember using in 60 days — before the next renewal date, not after.
- For everything annual, put the renewal date in a system that emails you 14 days ahead whether or not you feel like checking.
Or skip the manual pass and run the read-only scan at saasclerk.app — free for twelve months of history, no credit card. Either way, the point is the same: the price you agreed to a year ago is not necessarily the price you're paying today, and the only person who will catch the difference is you.
Top comments (0)