DEV Community: Posting Dude

Your Uptime Monitor Can't See a Dead Cron Job. Heartbeat the 5 Jobs a Tiny SaaS Runs.

Posting Dude — Sun, 18 Oct 2026 06:24:23 +0000

Most tiny SaaS apps have a handful of jobs that run on a timer and nobody watches. A nightly database backup. A job that sends trial-ending emails. A sync that pulls subscription state from Stripe so your own table doesn't drift. Something that cleans up expired sessions or old uploads. Maybe a weekly digest.

Your uptime monitor checks that the homepage returns 200. It has no idea whether any of those ran last night. The site is up, the dashboard is green, and the backup job could have been failing since a dependency update nine days ago. You find out the day you need the backup.

The fix is small and boring: a heartbeat for each job. The job pings a URL when it finishes, and if the ping doesn't arrive on time, you get an alert. It's sometimes called a dead man's switch. Here's how I'd set it up when you have under 100 users and one person on call (you).

I'll use Healthchecks.io's pinging API for the examples because the docs are clear and the free Hobbyist plan covers 20 jobs, which is more than a tiny app needs. Cronitor, Better Stack and Sentry Crons do the same basic thing. The pattern matters more than the tool.

1. Write down every job first

Before any tooling, make a list. For each job, one line:

Job	Schedule	Where it runs	What breaks if it stops
DB backup	daily 02:00	VPS crontab	you can't restore
Trial-ending emails	hourly	worker	people get charged with no warning
Stripe reconcile	daily 03:00	worker	access drifts from billing
Session cleanup	daily	Vercel cron	table grows, slowly
Weekly digest	Mon 08:00	GitHub Actions	nobody notices for a while

The last column decides how loud the alert should be. A missed backup or a missed billing job should reach your phone. Session cleanup can be an email you read tomorrow.

Doing this list is usually where you find a job you forgot existed, or one that lives on a platform you stopped thinking about.

2. One check per job, matched to the schedule

Create one check per job. Don't share a check between two jobs, or one of them can die while the other keeps it green.

For the schedule you have two options:

Period + grace. "Expect a ping every 24 hours, wait 1 extra hour before alerting." Simple, and fine for most jobs.
Cron expression + timezone. Paste the same expression as your crontab and set the server's timezone. Healthchecks.io then checks the job ran at the right time, not just at roughly the right interval. If your server isn't on UTC, the timezone field matters, because cron uses the machine's local time.

Grace time is the setting people get wrong. Too short and every slow night pages you. Too long and you hear about a failure half a day late. I'd start with roughly the job's normal run time plus a margin, then tighten it after a couple of weeks of real data.

3. Ping on success, and ping failure explicitly

The basic version is one line at the end of the job:

curl -fsS -m 10 --retry 5 -o /dev/null https://hc-ping.com/your-uuid-here

-m 10 stops the ping from hanging your job, --retry 5 retries on timeouts and transient server errors, and -fsS keeps it quiet unless something goes wrong.

That alone catches the job not running at all. To find out sooner when it runs and fails, send the exit code. Healthchecks.io treats /0 as success and any other number as a failure:

#!/bin/bash
set -o pipefail
pg_dump -Fc mydb | gzip > /backups/mydb-$(date +%F).dump.gz
curl -fsS -m 10 --retry 5 -o /dev/null https://hc-ping.com/your-uuid-here/$?

The set -o pipefail line is the one that bites. Without it, a pipeline's exit code is the last command's. So if pg_dump fails but gzip happily compresses nothing, the script reports 0 and your heartbeat says the backup worked. That's an empty file with a green check next to it.

In app code it's the same idea:

import requests

URL = "https://hc-ping.com/your-uuid-here"
ok = False
try:
    ok = run_trial_reminders()  # return True only if it actually did the work
finally:
    requests.get(URL if ok else URL + "/fail", timeout=10)

4. Add /start to catch hung jobs

A job that hangs is worse than one that crashes, because it never reaches the line that reports failure. Ping /start when the job begins:

curl -fsS -m 10 --retry 5 -o /dev/null https://hc-ping.com/your-uuid-here/start

If a start arrives and no success follows within the grace time, the check goes down and you get alerted. You also get run durations for free, which is how you'd notice a backup that used to take 4 minutes now takes 40.

If the same job can overlap with itself, pass a run ID (?rid=<uuid>) on both pings so durations don't get mixed up.

5. "It ran" is not "it worked"

The quiet failure is a job that runs on time, exits 0 and does nothing. The reconcile job that fetched zero subscriptions because the API key got rotated. The email job that found zero trials ending because a query filter broke.

Two cheap ways to catch that:

Send a number in the ping body. Healthchecks.io stores the first 100 kB of a POST body, so post something like checked=37 updated=2. When something looks off, the history is right there.
Fail on "suspiciously zero". If the reconcile job normally touches 30+ customers and today it saw 0, ping /fail instead of success. You'll get the odd false alarm on a quiet day. That's cheaper than a week of drift.

For backups, the heartbeat proves the dump ran. It doesn't prove you can restore it. I wrote up a monthly restore drill for a solo SaaS for that part.

6. Platform crons have their own catches

If your jobs don't live in a crontab, read the small print. A few I'd check:

Vercel cron jobs are best effort. Vercel's docs say it won't retry a failed invocation, and occasionally a request may not reach your function at all, with no runtime log for that run. On the Hobby plan, crons are limited to once a day and a 0 1 * * * job can fire anywhere between 1:00 and 1:59. Vercel also says a long job can overlap with the next run, and recommends locks plus idempotent jobs so a duplicate or missed run is safe.
GitHub Actions schedules can be delayed at busy times, especially the top of the hour, and under heavy load some queued runs can be dropped. In a public repo, scheduled workflows are disabled automatically after 60 days with no repository activity. A weekly digest living in a quiet repo will simply stop one day.
Your own VPS crontab only "alerts" by emailing job output, which needs MAILTO and a working mail setup. On a lot of servers that was never configured, so the output just goes nowhere.

A heartbeat covers all three the same way: if the ping doesn't show up, you hear about it. For Vercel and GitHub Actions, schedule a few minutes off the hour and set the grace time to cover the platform's timing window.

7. Send alerts where you'll actually see them

Pick two levels and stop there:

Wake me up: backup, billing-related jobs, anything where a missed run costs money or data. Phone push or a chat app with notifications on.
Tell me today: cleanup, digests, nice-to-haves. Email is fine.

Then test it. Pause a job or point its ping at /fail once, and confirm the alert actually reaches you. An alert channel you've never seen fire is the same as no alert channel.

This fits into a bigger question of what to watch on a small app when you can't stare at dashboards all day. The SideHunt guide on monitoring a side project during your day job covers uptime checks, error alerts and alert tiers around it, so I won't repeat it here.

The 20-minute version

If you only do the minimum today:

List your scheduled jobs and where each one runs.
Create one check per job, with a grace time that matches how long it normally takes.
Add the exit-code ping at the end, with set -o pipefail in shell scripts.
Force one failure and make sure the alert reaches your phone.

That's it. Don't be surprised if the first alert is for a job you'd forgotten about.

How many scheduled jobs does your app run right now, and do you know for sure that each one ran last night?

Before You Post a Launch-Day Promo Code in Stripe, Set These 5 Limits

Posting Dude — Sat, 17 Oct 2026 06:25:06 +0000

Launch day is when most tiny SaaS founders make their first public discount code. You open Stripe, make a coupon, type LAUNCH50, paste it into the launch post and the first comment, and go back to replying to people.

That works. It also leaves a code on the internet that you haven't really decided anything about. How long does the 50% last? Who can use it? When does it stop? What happens if it ends up on a coupon site next month?

When you have under 100 customers, every one of those answers shows up in your MRR for a long time. So here's the checklist I'd run before posting the code. It's based on Stripe's coupon and promotion code docs, not on any special trick. Not legal or tax advice.

1. Coupon vs promotion code: post the code, not the coupon

Stripe has two objects and it's easy to mix them up.

A coupon is the discount logic: percent or amount off, how long it lasts, which products. You (your backend, or you in the Dashboard) apply it to a subscription. The customer never types anything.
A promotion code is the customer-facing string, like LAUNCH50, that points at a coupon. Many codes can point at the same coupon.

For a public launch you want a promotion code. That's the one with the controls that matter here: first-time customers only, a minimum spend, an expiry date, a redemption cap, and you can switch it off without deleting anything.

The part people skip: since many codes can point at one coupon, make one code per place you post it. Same 30% off coupon underneath, but PH30 for one launch platform, IH30 for another, NEWS30 for your own email list. Each promotion code has its own redemption count, so a week later you can see which audience actually paid, not just which one clicked. With 20 launch-week signups that's often the only clean attribution you'll get.

2. Pick the duration on purpose

The coupon's duration is the setting with the longest tail. There are three values:

Duration	What it does	Use it when
`once` (default)	Applies to the first invoice only	You want a launch "first month cheaper"
`repeating` + `duration_in_months`	Applies to every invoice in that window	You want "3 months at 30% off"
`forever`	Every invoice, indefinitely	Almost never for a public launch code

Two traps worth knowing:

Forever plus an expiry date doesn't mean what it sounds like. The expiry only stops new people redeeming it. Anyone who used it before the date keeps the discount forever, per Stripe's docs. So a "launch week only, 50% off forever" code is really "everyone from launch week pays half until they cancel". At 15 customers that might be fine. At 60 it's a permanent hole in your revenue that you set up in 30 seconds. If that's actually what you want, it's basically a lifetime deal and deserves the same thinking (I like this breakdown of what a lifetime deal costs a small SaaS later).

Repeating coupons and annual plans. Stripe applies a repeating coupon to every invoice in the window. On a yearly plan, if the subscription renews within that window, the discount covers the whole year. So "3 months at 50% off" on an annual plan can turn into a year at 50% off. If you offer both monthly and yearly, either restrict the coupon to the monthly product or make a separate one for yearly.

3. Set the four limits before you post

On the promotion code (not just the coupon), set these:

Expiry date (expires_at). Pick a real end, like the end of launch week in your time zone. If the coupon itself has a redeem_by, the code can't expire later than that.
Max redemptions. A cap you'd be happy with even if every redemption came from strangers. The coupon's cap is shared across all codes pointing at it, and a code's cap can't be bigger than the coupon's. So if you make PH30 and IH30 from one coupon capped at 50, that's 50 total, not 50 each.
First-time order only (first_time_transaction). Stops your existing customers from switching to a cheaper code. But read the next section before you tick it.
Minimum amount (optional). Only checked on the first payment of a subscription, so it's not a way to protect later invoices.

Once a promotion code hits its cap or its expiry date, it's permanently inactive and can't be switched back on. That's what you want. If you need more, make a new code.

4. The first-time-only trap if you ran a trial

This one is easy to miss for launch day specifically.

Stripe's first-time-only rule blocks anyone with prior transaction history. That includes someone who started a PaymentIntent that never completed, and someone who started a trial, even if it was canceled.

Now picture a normal pre-launch: you've had a free trial open for a month, 30 people tried it, and on launch day you email them "here's 30% off if you upgrade this week". If the code is first-time only, a lot of those people will hit an error at checkout. They're exactly the warm people most likely to pay.

So decide which audience each code is for:

Code for strangers on launch platforms: first-time only is fine.
Code for your trial users or waitlist: leave first-time off, and use a lower cap or a customer-specific code instead. Promotion codes can be restricted to one specific customer, which is the cleanest option when the list is small enough to do by hand.

5. Make the code actually usable, then check where it shows up

A few things that cause launch-day support emails:

Checkout needs the box turned on. If you use Stripe Checkout, the promo field only appears when the Checkout Session is created with allow_promotion_codes enabled. Easy to forget when you've never used a discount before. Test it with the actual code in test mode.
Codes are case-insensitive and must be unique among active codes, so launch50 and LAUNCH50 are the same thing. You can't have two active public codes with the same string.
The Customer Portal can show and accept codes. If you turned on promotion codes in the portal, customers can apply them when they change plans, and the portal displays the codes already applied to their subscription. If you'd rather a code not get passed around, set limits on it or apply a coupon directly instead. I wrote up the portal settings I'd start with in turning on Stripe Customer Portal before 50 customers.
A once coupon disappears from the subscription after it's used. After the invoice that used it finalizes, the subscription's discounts no longer includes it. The invoice still shows it. So if your app reads "does this subscription have a discount?" to show a badge or decide something, it'll say no after month one. Read the invoice if you need history.

When launch week is over

Don't delete the coupon to "end" the promo. Deleting a coupon doesn't remove the discount from subscriptions that already have it; it just stops new redemptions (and archives its codes). Usually the expiry date has already done the job. If a code leaks somewhere you didn't post it, archive just that promotion code by setting it to inactive. Your other codes keep working.

Then look at the per-code redemption counts. That's the useful launch-day data: which audience actually paid with a discount. Whether they'd have paid without one is a separate question, and with this few customers you can just email them and ask. If you're still in the reply-to-everyone phase of the launch, this playbook on turning launch-day comments into paying users pairs well with the per-code numbers.

All of the settings above are in Stripe's coupons and promotion codes docs if you want the API names next to the Dashboard ones.

If you've posted a launch code before: did you make one code for everywhere, or one per platform? And did anyone end up with a "forever" discount you didn't mean to give?

Turn On Stripe Customer Portal Before You Hit 50 Customers

Posting Dude — Fri, 16 Oct 2026 06:20:27 +0000

When you have under 50 paying customers, "update my card", "can you send the invoice", and "I want to cancel" still land in your inbox. You open the Stripe Dashboard, find the customer, click around, paste a screenshot, apologize for the delay. It works. It's also a bad habit that gets worse every week you wait.

Stripe's Customer Portal is the cheap offload for that size. Hosted UI. You configure which features are on. Customer does the billing chores themselves. You stop being the human middleware between their card and Stripe.

This is the operational order I'd use before you hit 50 — not because 50 is magic, just because after that the email volume makes the Dashboard click-path painful. Not legal advice. Grounded in Stripe's customer portal docs.

1. What to turn on first (minimal config)

Configure the portal in the Dashboard (or via portal Configurations in the API). Live mode and sandbox each have their own config — changing one does not change the other. Easy to forget when you tested everything in test mode and then wonder why live customers see different buttons.

For a tiny SaaS under ~50 customers, turn these on first:

Feature	Start with	Why
Payment method update	On	Stops "my card expired" emails
Invoice history (view / pay / download)	On	Stops "send me last month's invoice" emails
Cancel	On, at period end	Stops you doing cancels by hand; keeps access until paid-through
Update billing info / tax IDs	On if you charge tax or need company details	Optional early
Subscription update (plan change / quantity)	Off until you have a real catalog + proration story	Plan upgrades without prices is a trap

Leave plan upgrades off until you've set a product catalog the portal can actually show. Stripe requires that catalog if customers can upgrade, downgrade, or change quantities. Under 50 people, you can still change plans for them in the Dashboard when someone asks. Self-serve upgrades without clear prices just creates weird mid-cycle invoices you'll have to explain.

Cancel at period end is the default I'd pick at this size. Immediate cancel is fine for some products; just don't leave it on by accident because you clicked through the settings once.

Preview from the Dashboard: open a sandbox customer → Actions → Open customer portal. Read-only Preview exists while you tweak settings. Use it before you put a button in production.

2. One "Manage billing" button (not a permanent URL)

The integration is small:

Customer is logged into your app (authenticate first — Stripe is clear on this).
Your backend creates a Billing Portal Session with their Stripe customer ID and a return_url.
Redirect them to session.url.

Something like:

POST /create-portal-session
→ stripe.billingPortal.sessions.create({
    customer: cus_xxx,
    return_url: "https://yourapp.com/account"
  })
→ redirect to session.url

Sessions are short-lived. Stripe's docs: a new portal session expires after about 5 minutes if unused; if the customer uses it, it expires within about 1 hour of the most recent activity. So don't paste a permanent portal URL into email and hope it works next week. Create a session when they click, then redirect.

There's also a shareable login_page link per configuration. Treat that as a special case, not your default. The normal path is: auth on your site → create session → redirect. Don't use the customer billing email as a login credential either — billing email updates in the portal are billing info, not account login.

3. Deep links for the three emails you already send

Once the homepage portal works, deep-link the emails you're already writing. Set flow_data[type] when you create the session. Navigational chrome for the rest of the portal is hidden so they land on one action.

Email you already send	`flow_data[type]`	Notes
Failed payment / expired card	`payment_method_update`	Put this in dunning and "card expiring" mail
"I want to cancel" / cancel confirmation	`subscription_cancel`	Pass the subscription ID; pair with period-end cancel
Tax ID / address / company name	`customer_update`	Added as a portal deep link in Stripe's 2026-08-26 changelog

Also available when you need them later: subscription_update, subscription_update_confirm. Skip those until plan changes are actually enabled in the config.

Top-level return_url is the "back to your site" link they can use anytime (e.g. they decide not to cancel). flow_data[after_completion] can redirect after they finish the action, show a hosted confirmation, or send them to the portal homepage. For cancel emails, a clear after_completion redirect back to your account page is less confusing than dumping them on a generic Stripe screen.

You don't need fancy copy. You need the link to open the right screen on the first click.

4. Webhooks so access matches what they did

The portal changes Stripe objects. Your app's entitlements have to follow. From Stripe's integrate guide, the ones that matter for a tiny setup:

Event	Why you care
`customer.subscription.updated`	Plan change, quantity, or cancel scheduled at period end (`cancel_at_period_end` / `cancel_at` depending on billing mode)
`customer.subscription.deleted`	Subscription actually ended — revoke access here if you cancel at period end
`payment_method.attached` / `detached`	Card changed; useful for support and for clearing "update card" banners
`customer.updated`	Billing details / default payment method changed — don't treat billing email as login

The cancel trap: if the portal is set to cancel at period end, the first signal is usually customer.subscription.updated with cancel-at-period-end set, not deleted. If you revoke access on that update, you cut them off while they still paid through the period. Keep access until deleted (or until current_period_end / cancel_at actually passes — same idea). If they reactivate before the end, you'll get another updated with cancel cleared — restore "not leaving" state, don't invent a new subscription.

Same discipline as any other Stripe webhook: verify the signature on the raw body, store event.id for idempotency, re-fetch the subscription if you're unsure about ordering.

5. Traps that show up under 50 customers

Cancel left on "immediate" by accident. Someone cancels on day 3 of a monthly plan and loses access the same afternoon. If that's intentional, fine. If you meant period end, fix the config before the next person finds it.

Plan changes enabled with no (or wrong) catalog. Empty upgrade UI, or prices you never meant to sell. Keep subscription update off until the catalog is real.

Shareable login_page link as your only path. Convenient for a quick support paste. Worse for security hygiene than auth → session. Don't make it the product default without thinking.

Treating portal cancel as "access already gone" when cancel-at-period-end is true. See webhooks above. Your paywall and your email should agree: "you're paid through [date], then it ends."

Forgetting live-mode config is separate from test. You polished sandbox. Live still has defaults. Flip View test data off, configure live, add live webhooks, then ship the button.

Emailing a stale session URL. Five-minute unused expiry is short. Always create a fresh session from a button or a signed link on your domain.

If cancel UX is the part you're nervous about (retention copy, confirmation, what happens to data), that's a product design problem next to the portal config — how to design a cancel flow without dark patterns is the frame I'd use so the portal cancel screen and your in-app copy don't fight each other.

Portal also shows up in other small-scale ops — especially trial-ending mail that needs a card update before the first charge. If you're still wiring that flow, when a free trial ends under ~40 active trials is the sibling checklist. Source of truth for the portal itself: Stripe's customer portal overview and the API integrate guide.

If you're under 50 customers: what do you leave on vs off in the Customer Portal right now — and did you set cancel to period end or immediate on purpose?

why launch days feel empty: makers couldn't see visitors/clicks, so they didn't bring their audience. shipped live maker stats on aura++ https://auraplusplus.com/projects/kai/live?utm_source=devto&utm_medium=social&utm_campaign=bip-aura-maker-live-stats

Posting Dude — Thu, 15 Oct 2026 06:30:36 +0000

Recorded launch-day visitors, upvotes, outbound clicks, and comments for Kai on Aura++.

auraplusplus.com

When a Free Trial Ends and You Have Under 40 Active Trials

Posting Dude — Thu, 15 Oct 2026 06:29:44 +0000

When you have under 40 active free trials, the hard part isn't starting them. Stripe Checkout will do that with a couple of fields. The hard part is the last three days, when a trial is about to become a charge, or nothing, or a paused subscription you forgot about.

Most tiny SaaS setups stop at trial_period_days=14. They never decide what access looks like on the morning the trial ends, what email goes out, or what Stripe should do if there's no card on file. Then the first trial ends on a Tuesday and you're inventing policy in the Dashboard.

This is the operational side for that size. Not legal advice, just the order I'd set things in before the next trial hits day 11.

1. Know what Stripe actually fires (and when)

For the classic free trial (trial_end / trial_period_days), Stripe sends customer.subscription.trial_will_end three days before the trial ends. If the trial is shorter than three days, it fires basically immediately. That's the default on the Dashboard "Trial ending events" setting — you can change the lead time, but three days is what most accounts get.

Two things people mix up:

trial_will_end is a reminder, not the end. The subscription is still trialing when this lands. Nothing has charged yet.
Stripe's own hosted reminder email (the compliance one in Billing settings) is a different clock. Their docs put it at seven days before the trial ends. So you can get Stripe's email on day 7 of a 14-day trial, and your webhook on day 11. Don't assume they're the same day.

When the trial actually ends and the sub isn't paused, Stripe creates an invoice and attempts to charge it roughly an hour later. You'll also see customer.subscription.updated as status moves from trialing toward active (or into trouble).

If you already keep an entitlements table off Stripe status alone, treat trial_will_end as "check the customer has a usable payment method, then send your email." Don't wait for the charge to fail and then scramble.

2. Card-upfront vs no card: pick one, then set `missing_payment_method`

Two common shapes under 40 trials:

A) Card at signup. Checkout collects a payment method, trial starts at $0, day N they get charged. Simpler ops. Higher signup friction. Abuse is lower.

B) No card during trial. Faster signups, more junk accounts, and you must tell Stripe what to do when the trial ends with nothing to charge. That's trial_settings.end_behavior.missing_payment_method:

Value	What Stripe does at trial end	Webhook you care about
`create_invoice` (default)	Creates an invoice; if it can't be paid, sub can go `past_due`	`invoice.created` / `invoice.payment_failed`
`cancel`	Cancels the subscription	`customer.subscription.deleted`
`pause`	Pauses; no more invoices until you resume	`customer.subscription.paused`

Stripe checks default_payment_method and default_source on both the subscription and the customer. If either has a usable method, it's not "missing."

For a tiny product with a real cost to serve (AI calls, storage, support), cancel is usually cleaner than leaving paused zombies. pause is useful if you want a soft "come back and add a card" path via the Customer Portal without creating a new subscription. create_invoice without a card is how you accidentally farm past_due rows.

Don't leave this unset and assume cancel. The default is invoice, not cancel.

(Stripe also has a newer "Trial Offers" API for flexible billing. Most indie Checkout setups still use the legacy trial_period_days path above. Same webhook names either way for the reminder.)

3. The emails: three messages, not a drip

You don't need a seven-email sequence at this size. You need three decisions written down:

1. Mid-trial (optional, day 3–5 of a 14-day trial). Only if they haven't hit your activation event. One short "here's the one thing to try" note. Skip it if they already did the thing. Calendar drips that ignore usage just train people to ignore you.

2. The trial_will_end email (your own, ~3 days out). This is the one that matters. Subject should say the date and the amount, not "Your trial is ending soon!!"

Something like:

Subject: Your trial ends Thursday. $29/mo starts then

Hey [name],

Your trial of [product] ends on [date]. If you keep the plan,
we'll charge $[amount] on that day to the card on file.

If you want to stop, cancel here before then: [portal or cancel link]

If the card isn't current, update it here: [portal / update link]

[your name]

Rules: no feature laundry list, no fake urgency, one cancel path that actually works. If there's no card on file (shape B), swap the middle for "add a payment method to keep access" and link the Customer Portal. Stripe's free-trial docs literally walk that portal flow off trial_will_end.

3. Day-of / day-after.

Charged successfully → short receipt + "you're on the paid plan" (or rely on Stripe's receipt if you've tested it lands).
No card + cancel → "trial ended, account is closed, here's how to start again if you want."
No card + pause → "paused, add a card to resume" with the portal link.
Payment failed → that's not a trial email anymore; treat it like a failed renewal (same tone as a failed-payment recovery mail, not a marketing nudge).

Under 40 trials you can send these from Resend/Loops/Postmark with a spreadsheet of trial end dates if webhooks feel scary. Webhooks are better once you're past a handful a week — but a missed webhook during a deploy is how someone gets charged with no warning. If you use webhooks, verify signatures and don't trust event order; re-fetch the subscription.

4. Access on the day the trial ends

Write this before the first trial ends. Same idea as a refund policy: inventing it while someone is logging in goes badly.

Rough matrix that works at small scale:

Situation	Access I'd give
Still `trialing`	Full product (or whatever the trial promised)
`trial_will_end` fired, card on file	Full access; show a calm banner "paid plan starts [date]"
Trial ended, `active`, invoice paid	Full paid access
Trial ended, payment failed / `past_due`	Keep access for a short grace (e.g. 3–7 days) with a banner, then read-only or lock — match whatever you do for normal failed renewals
Trial ended, `canceled` (no card + cancel)	No access. Export/download if you promised data out.
Trial ended, `paused`	No (or read-only) access until they resume with a card

The mistake is checking only status === 'active'. A trial that just ended can sit in paused, canceled, past_due, or briefly look weird while the first invoice is open. If you've read how Stripe's eight subscription statuses actually map to access, you already know active alone lies in both directions.

Also decide: do trial users keep data after cancel? If yes for 30 days, say so in the day-of email. If you wipe on cancel, say that too. Silence here creates support tickets that feel like betrayal even when you did nothing sneaky.

5. A boring checklist before you open trials

Copy this into a note only you see:

Trials (internal)
- Length: __ days
- Card at signup: yes / no
- missing_payment_method: cancel / pause / create_invoice
- trial_will_end email: on (own template) / Stripe-hosted only
- Access on cancel: lock now / read-only __ days
- Access on pause: lock / read-only
- Grace on failed first charge: __ days
- Webhook events: trial_will_end, updated, deleted, paused, resumed,
  invoice.paid, invoice.payment_failed
- Test with a test clock: happy path, no card, failed card

Run the test clock once. The "no card + cancel" path and the "card declines on first charge" path are the ones that surprise people in week three.

6. One product decision this is not

This whole post assumes you already picked a free trial (not freemium, not both). If you're still deciding the access model, that's a different problem. choosing free trial vs freemium before PMF is the decision frame I'd use first. Ending mechanics won't save a trial you never should have offered.

For the Stripe field names and the no-card cancel/pause setup, the source of truth is Stripe's free trial docs. The event timing table lives in their subscription webhooks guide.

If you're running trials right now: card at signup or not, and on the day it ends do you lock access immediately or leave a grace window? What broke the first time a trial actually ended?

When Someone Asks for a Refund and You Have Under 30 Paying Customers

Posting Dude — Wed, 14 Oct 2026 06:23:10 +0000

When you have under 30 paying customers, refund requests are rare. Maybe one every month or two. But each one is loud. It's one person out of a small group telling you something didn't work, it's real money leaving a pretty small balance, and it's a question about access you probably never answered on purpose.

Most founders treat it as a Dashboard click. The click is the easy part. The decisions around it are where small SaaS gets messy, and they're much easier to make before the first email shows up than while you're reading it.

This is the order I'd go in. Not legal advice, just the operational side.

1. Decide what happens to access before anyone asks

When a refund email comes in, the first question isn't "how much". It's "do they keep using the product after this?"

There's basically three options for a small subscription product:

Refund + cancel now. Money back, access ends today. Cleanest. Good for "I signed up by mistake" or "this isn't what I thought it was".
Refund + keep access until period end. Money back, but they can still log in until the date they already paid for. Feels generous, costs you nothing extra, but you're giving away a month of usage.
Partial refund + keep the plan. For "the feature I needed was broken for a week" type cases. You refund part of the charge and they stay a customer.

None of these is the right one. The mistake is picking a different one every time depending on your mood or how nice the email was. Two customers who asked for the same thing should get the same answer.

So write it down. Literally three or four lines in a doc only you read:

Refund policy (internal)
- First charge, asked within 14 days: full refund, cancel now
- Renewal they forgot about, no usage since renewal: full refund, cancel now
- Product broken for them for a real stretch: partial refund, keep plan
- Anything else: reply first, decide after

The 14 days is just an example, use your own number. The point is you're not inventing policy at 11pm with an annoyed customer waiting.

2. Reply once before you refund (unless it's obvious)

If the reason is obvious, like a duplicate charge or they forgot to cancel and haven't logged in since, just refund it. Don't make people explain themselves for that.

If it's not obvious, send one short reply first. Not to argue or talk them out of it. Under 30 customers, the reason they want out is worth more to you than the money in most cases, and it's the only time they'll tell you.

Something like:

Hey [name],

Sure, I can sort that out. Before I do, can I ask what
didn't work for you? Even one line helps, I'm a small team
and I read every one of these.

If it was something broken, tell me and I'll check
whether it's still happening.

[your name]

Rules for this email: no discount offer in the first reply, no "are you sure", no list of features they "might have missed". Just a question. If they don't answer in a couple of days, refund anyway and move on. Holding the refund hostage for feedback is how a refund request turns into something worse.

And that's actually the other reason to be quick and polite here. A customer who feels ignored can go to their bank instead of you. If you've read why one dispute already looks like a 1% rate when you're small, you know a refund is almost always the cheaper outcome.

3. The Stripe mechanics, as a checklist

Here's what's worth knowing before you click, mostly from Stripe's refund docs:

Full or partial. The Dashboard defaults to a full refund, you can type a smaller amount for partial. You can do more than one partial refund on the same charge, but the total can't go over the original amount. The API takes an amount in the smallest currency unit (cents for USD).
Pick a reason. The Dashboard asks for one. If you choose "Other" you have to write a note, which is honestly useful later.
Fees don't come back. Stripe's processing fees from the original charge aren't returned when you refund. So a refund costs you a little more than the refund amount. Not a reason to refuse, just know it.
Refunds come out of your available balance. Not pending money. If you just got paid out and your available balance is low, Stripe holds card refunds as pending until there's enough. With a tiny customer base that can actually happen.
Original payment method only. You can't send it to a different card or bank account. If their card expired, the issuer usually routes it to the replacement card.
Timing. Stripe says the customer sees the credit roughly 5â€“10 business days later depending on their bank. If you refund very soon after the charge, it can show as a reversal instead: the original charge just disappears from their statement and no separate credit shows up. Worth telling the customer, because "I don't see a refund" is the most common follow-up.
Email to the customer. There's a Dashboard setting to email customers about refunds. It only sends if the charge was on a Customer in your account and that Customer has an email. Turn it on or send your own, but don't send nothing.
Don't refund into an open dispute. If they already disputed the charge with their bank, go through the dispute instead. Stripe's docs say if a customer disputes while a refund is pending, the refund can fail with charge_for_pending_refund_disputed, and they recommend accepting or challenging the dispute rather than refunding, so you don't pay them back twice. For bank debit methods (SEPA, ACH, Bacs etc.) they flag the double refund risk directly.
Refunds can fail. Closed account, card problem, lost or stolen card. Stripe sends refund.failed, and the money comes back to your balance (can take up to 30 days). Then you need some other way to pay them back. If you already have webhooks, add a listener for it.
The reference number. If someone says the money never arrived, open the payment, go to the Timeline, View Details on the refund. Where available Stripe shows an ARN (or STAN/RRN). Give that to the customer, their bank can trace it. It can take up to 7 business days to show up, and there isn't one for reversals.

4. After the refund, close the loop

The refund going through isn't the end. Three small things:

Do the access change you decided in step 1. If it's "cancel now", cancel the subscription now so there's no renewal next month. A refund on a charge doesn't cancel the subscription by itself. If it's "keep until period end", set it to cancel at period end and check your app actually respects that date. Refunding someone and then charging them again 30 days later is the fastest way to get a dispute.

Send a short confirmation. Amount, that it goes back to the card they paid with, the 5â€“10 business day window, and that a quick refund might show as the charge just disappearing. One paragraph.

Log it. One row in a sheet. Stripe has the payment data, but it doesn't know your access decision or what the customer actually said.

date       | customer        | amount | full/partial | reason (their words)          | access        | notes
2026-10-14 | jane@acme.test  | $29    | full         | "needed CSV export, no CSV"   | cancel now    | 2nd ask for CSV

That "reason in their words" column is the one that matters. At 30 customers you won't see patterns in Stripe charts, but you'll see them in eight rows of a sheet. If three of those rows say some version of the same missing thing, that's your roadmap telling you something.

Also worth separating these from failed payments. A refund is a customer choosing to leave and telling you. A failed card is someone leaving without choosing to, and that needs a different setup, like failed payment emails for involuntary churn. Don't mix both into one "churn" number or you won't know which problem you have.

5. Make the exit not hurt

A lot of refund emails happen because cancelling was confusing or someone didn't realise they'd renew. Hide the cancel button and people email you for a refund instead, or go to their bank. If you want to fix the part before the refund request, this guide on designing a SaaS cancel flow without dark patterns covers how to make leaving easy while still asking the one question you'd want answered.

For people who've already issued a few refunds on a small product: did you keep access until period end, or cut it off the same day? And did either choice ever come back to bite you?

Shipped a free AI Visibility Score on Aura++. Ran EarlyHunt first: 53/100, F. Crawlers and on-page both 20/20. AI recall 0/40. https://praneetbrar7.medium.com/my-launch-site-scored-0-40-on-ai-recall-its-seo-checks-were-all-green-546dc57d32f5

Posting Dude — Tue, 13 Oct 2026 06:39:09 +0000

praneetbrar7.medium.com

Under 100 Payments a Month, One Stripe Dispute Is Already a 1% Dispute Rate

Posting Dude — Tue, 13 Oct 2026 06:38:21 +0000

Here's some math nobody puts in the Stripe tutorial. If your SaaS does 100 payments a month and one customer disputes a charge, your dispute rate for that month is 1%. Stripe's own docs say the card industry treats dispute activity above 0.75% as excessive.

One dispute. That's all it takes when you're small. To be fair, the card networks judge this over months, not one bad week, so a single dispute isn't getting you fined. But your numbers look bad very fast and there's almost no room.

Stripe even calls this out in its fraud best practices: a business with fewer than 100 payments a month is one where "one or two fraud disputes can have a very outsized impact" on the dispute rate. So the playbook for a tiny SaaS is a bit different from the one you read in big-company posts. Here's what I'd set up, and what each dispute actually costs you.

What a dispute costs (US numbers, from Stripe's pricing page)

Dispute received fee: $15. Charged the moment the dispute opens. On standard pricing, outside Mexico, you don't get it back, even if you win.
Dispute countered fee: $15. Only if you respond with evidence manually. You get this one back if you win.
Smart Disputes: Stripe's AI builds the evidence for you and charges 30% of the disputed amount, only on disputes it wins. The $15 received fee still applies.

So take a $29/month customer:

What you do	What you're out
Refund before any dispute exists	$29 (plus the original processing fee, which refunds don't return)
Accept the dispute	$29 + $15 = $44
Fight and lose	$29 + $15 + $15 = $59
Fight and win	$15

Fees vary by country (Stripe's India page lists ₹1,000 for each), so check yours. But the shape is the same everywhere: once the dispute exists, even winning costs money, and it counts toward your dispute rate whether you win or lose.

That changes the goal. At 100 payments a month the win isn't "fight every dispute well". It's "have fewer of them exist at all".

Prevention first: the three dispute reasons a small SaaS actually sees

Stripe has a list of dispute reasons. For a subscription product, the ones I'd worry about are these three.

1. unrecognized: they don't know what the charge is.
This one is so often avoidable. If your Stripe statement descriptor still says your legal company name or some old project name, people look at their card statement, see a charge they don't recognize, and call the bank. Stripe's guidance is to use a name or URL customers would associate with the purchase.

The rules: 5 to 22 characters, Latin characters only, at least one letter. If you use a shortened prefix for card charges it's 2 to 10 characters. For subscriptions you can't set a suffix on the PaymentIntent because Stripe creates those charges, so set statement_descriptor on the Product (or on the Invoice) instead. Also turn on receipts so there's an email to search for when they see the charge.

2. subscription_canceled: "I canceled and you kept charging me".
Usually this is someone who thought they canceled, couldn't find the button, or forgot the renewal was coming. Three cheap fixes:

Make cancel easy to find. A dark-pattern cancel flow is basically a dispute generator. There's a longer piece on how to design a cancel flow without dark patterns on Aura++, and almost all of it applies here.
Send a confirmation email when they cancel, and actually pass the cancel through to Stripe.
Turn on renewal reminders. In Billing settings there's "Send emails about upcoming renewals". It only works for subscriptions with collection_method: charge_automatically, which is most small SaaS setups anyway. Annual plans are where this matters most, nobody remembers a charge from 12 months ago.

3. fraudulent: a stolen card.
This is mostly card testing and junk signups, which I covered in a small defense stack for fake signups and card testing. The part that matters for disputes is the next section.

Early fraud warnings: refund faster than you think

Before a fraud dispute shows up, you'll often get an early fraud warning (EFW). Visa, Mastercard and JCB issuers send these when they suspect a payment was fraud. Stripe sends a radar.early_fraud_warning.created event for it.

Stripe's numbers: if you don't refund, about 40% of Visa and Mastercard EFWs become fraud disputes. Their general advice is to refund EFWs on charges roughly at or under your dispute fee, and that it's usually not worth it on charges more than 35% above the fee.

But the same docs list exceptions where refunding more aggressively makes sense, and "new or small business (say, fewer than 100 payments per month)" is one of them. A $29 charge is about twice the $15 fee, so by the general rule you'd maybe wait. At small volume I wouldn't. Refund it and save yourself the dispute.

Two details from the docs worth knowing:

Refunding doesn't erase the EFW. Visa counts EFWs in its VAMP monitoring program anyway. What the refund does is stop the same payment from also becoming a dispute, and a transaction that shows up as both is counted twice.
Refund the full amount. A fully refunded payment can't be disputed. A partially refunded one can still be disputed for the full amount.

In the Dashboard use "Refund as fraud", which also tells Stripe it was fraud.

The webhook gotcha: a dispute doesn't tell you which subscription

When a dispute comes in you get charge.dispute.created. You probably want to do something in your app: pause access, flag the account, at least email them. The catch is that the Dispute object has charge and a nullable payment_intent, but no invoice or subscription.

On API version 2025-03-31.basil or later, the Charge doesn't have an invoice field anymore either. Stripe's documented path is to look the PaymentIntent up in the invoice payments list:

curl -G https://api.stripe.com/v1/invoice_payments \
  -u "$STRIPE_SECRET_KEY:" \
  -d "payment[type]=payment_intent" \
  -d "payment[payment_intent]=pi_123" \
  -d status=paid

Each result has an invoice. Retrieve it, check that parent.type is subscription_details, and parent.subscription_details.subscription is your subscription id. If payment_intent was null on the dispute, retrieve the charge and use its payment_intent. The same lookup works for EFWs and refunds.

The events I'd subscribe to for this: charge.dispute.created, charge.dispute.closed (won or lost) and radar.early_fraud_warning.created. Skip them and your app doesn't know about a dispute or a fraud warning until someone opens the Dashboard.

When one arrives anyway

You usually get 7 to 21 days to respond depending on the card network, and if you miss the deadline you lose automatically. A few rules from the respond-to-disputes docs that catch people out:

You get one submission. You can't edit it or add files after. Gather everything first.
Banks don't click links. No "see our terms at...". Screenshot or PDF everything. Max 4.5 MB combined, and Mastercard caps evidence at 19 pages.
You can't refund a disputed charge while the dispute is open, even if you and the customer agree. Talking to them still helps, and if they withdraw you still have to submit a response.
Amex and Discover sometimes send an inquiry first. Answer it. Resolving at the inquiry stage means no dispute fee, and ignoring one can turn into a chargeback you can't win.

For a digital subscription, the evidence that matters is stuff your app already has, if you log it:

Your cancellation policy as shown to the customer, and how and when you showed it (a screenshot of checkout works)
Login or usage logs after the charge, with timestamps and IP addresses. Stripe lists this as access_activity_log
The renewal reminder or receipt email you sent
Any support emails with them

If you don't record something like a last_seen_at or a simple usage log today, this is a good reason to start. "They logged in 14 times after the renewal" is the kind of thing a bank can actually check against the claim.

Test it before it's real

Stripe has test cards for all of this:

4000000000000259: the charge succeeds, then gets disputed as fraudulent
4000000000005423: the charge succeeds, then gets an early fraud warning
4000000000001976: the charge succeeds, then gets an inquiry

Then respond with winning_evidence or losing_evidence as the uncategorized_text evidence (it's the "Additional information" field in the Dashboard) to simulate the outcome. Run each one once and check your webhook handler finds the right subscription, your app does what you wanted with access, and you'd actually notice the email.

If you've already set up the paywall side, this fits next to what each of Stripe's 8 subscription statuses should mean for access, since a lost dispute is one more way a customer ends up not paying.

If you're getting a small SaaS ready to put in front of people, I run Aura++, a launch platform for indie products, and early-stage products are exactly who it's for.

Question for anyone billing on Stripe: when you get an early fraud warning on a small charge, do you refund right away or wait to see if it turns into a dispute? And what's your cutoff amount?

Stripe Has 8 Subscription Statuses. Your Paywall Probably Checks One.

Posting Dude — Mon, 12 Oct 2026 06:35:24 +0000

Most tiny SaaS paywalls I've seen boil down to one line:

if (sub.status === "active") showTheApp();

It works on day one. It keeps working right up until a card fails, or someone signs up with a card that needs 3D Secure, or a trial ends with no card on file. Then that one line either locks out a person who is about to pay you, or keeps paid features on for someone who stopped paying weeks ago.

A reader on my Stripe webhook post raised exactly this in the comments, and it deserved more than a reply. So here is the boring part nobody puts in the tutorial: what each status actually means and what access I'd give for it when you have under 100 customers.

The 8 statuses, in plain words

From Stripe's own docs on how subscriptions work:

trialing: in a trial. Safe to give access.
active: in good standing. Note: active doesn't promise every old invoice is paid, only the ones that govern status under your settings.
incomplete: the first payment failed, or needs action (3D Secure), or is still processing. The customer has 23 hours to pay.
incomplete_expired: those 23 hours passed without a payment. It never bills. To come back they need a new subscription.
past_due: payment on the latest invoice failed or wasn't attempted. Stripe may retry while it sits here, but it isn't guaranteed.
unpaid: only happens if you picked it in your failed-payment settings. Retries are done, invoices keep getting created but aren't charged.
canceled: terminal. Can't be updated. Coming back means a new subscription.
paused: a trial ended with no payment method and you set the trial to pause instead of cancel.

The part that bites people: what happens after the last retry is your choice in the Dashboard. The sub can go to canceled, to unpaid, or just stay past_due. If you never opened that settings page, go look now, because your paywall logic depends on it.

What I'd actually do with each one

Under 100 customers, I wouldn't build anything clever. One function, one small table:

Status	Access	Why
`trialing`	full	they're trying it
`active`	full	paid
`past_due`	full, with a banner, for a grace window (say 7 days)	most failed renewals are an expired card, not someone leaving
`incomplete`	none yet, show a "finish payment" screen	they never paid the first invoice
`incomplete_expired`	none, send them back to checkout	it's dead, a new sub is needed
`unpaid`	read-only (can log in, export data, can't use paid stuff)	retries are over, but don't hold their data hostage
`paused`	read-only + "add a card to continue"	trial ran out without a card
`canceled`	free plan or read-only until period end, if you allow that	they chose to leave

The grace window on past_due is the one I'd fight for. Picture a customer at $29/month whose card expired over the weekend. If you hard-lock them on Monday morning, you've turned a card problem into a "this app is broken" problem, and some of them won't come back to fix the card. A banner that says "your last payment didn't go through, update your card" and still lets them work is kinder and it recovers more money.

That banner is only half of it. The other half is the emails you send while the retries run. I wrote up the three short emails I'd send when a payment fails with under 50 customers, and there's a longer playbook for recovering failed SaaS payments before they turn into churn on Aura++ if you want the full flow.

Store access, not just status

The mistake I'd avoid is calling Stripe on every page load to check status. Slow, and it breaks when Stripe has a bad minute. Instead keep your own row:

create table entitlements (
  user_id        bigint primary key,
  stripe_sub_id  text,
  stripe_status  text not null,
  access         text not null,      -- 'full' | 'read_only' | 'none'
  grace_until    timestamptz,
  updated_at     timestamptz not null default now()
);

Your app reads access. Only your webhook handler (and a nightly check) writes it. The mapping from stripe_status to access lives in one function, so when you change your mind about unpaid you change one place.

function accessFor(status, graceUntil, now = new Date()) {
  switch (status) {
    case "trialing":
    case "active":
      return "full";
    case "past_due":
      return graceUntil && now < graceUntil ? "full" : "read_only";
    case "unpaid":
    case "paused":
      return "read_only";
    default: // incomplete, incomplete_expired, canceled
      return "none";
  }
}

Set grace_until the first time you see past_due for that sub, and clear it when it goes back to active.

The webhook events that matter

You don't need to handle 40 event types. For this you need roughly:

customer.subscription.updated and customer.subscription.deleted: status changed, recompute access.
invoice.payment_failed: start the grace window, send the first email.
invoice.paid: back to normal, clear the banner.
invoice.payment_action_required: the card needs 3D Secure, send them a link to finish it.

Two things that go wrong here: events arrive twice and out of order. So on every event, re-fetch the subscription from Stripe and write its current status, don't trust the status inside the event payload. I went through the other ways Stripe webhooks break between test mode and production in an earlier post, idempotency included.

The nightly safety net

Webhooks get missed. Deploys happen at the wrong moment, endpoints return 500 for ten minutes. So once a night, list your subscriptions from Stripe, recompute access for each, and log any row where your table disagreed with Stripe. Under 100 customers that's one API page and a few seconds. If that log is ever non-empty, you just found a bug in your webhook handler for free.

A quick test before you trust it

Stripe's test cards make this easy to check in an afternoon:

Create a sub with a card that requires authentication and don't complete it. You should see incomplete and your "finish payment" screen.
Create a sub with a normal test card, then swap the default payment method to a card that declines and advance a test clock past the renewal. You should land in past_due, with full access and the banner.
Keep advancing past your retry window. You should land wherever your Dashboard setting says (canceled, unpaid or still past_due), and your app should match.

If step 3 surprises you, that's the whole point of doing it.

If you're getting a small SaaS ready to put in front of people, I run Aura++, a launch platform for indie products, and early-stage stuff is exactly what it's for.

Curious how others handle it: when a renewal fails, do you keep full access during retries, go read-only right away, or lock it? And how long is your grace window?

My app was down 40 min once. Nobody complained about the 40 min. They complained that they found zero sign I knew. Now my 500 page links a status page on a different host, and I post "next update in 30 min" even when I have nothing new.

Posting Dude — Sun, 11 Oct 2026 06:20:21 +0000

My Tiny SaaS Went Down for 40 Minutes. The Outage Was Fine, the Silence Wasn't.

Posting Dude — Sun, 11 Oct 2026 06:19:39 +0000

A few months back my app was down for about 40 minutes on a weekday evening. Database host had a bad node, nothing I did. I fixed it, it came back, I went to sleep feeling ok.

Next morning I had two emails. One said "is this thing abandoned?" The other was a cancellation with no reason given. Neither person was mad about the 40 minutes. They were mad that they hit an error page, checked twitter, checked my site, found nothing, and assumed nobody was home.

That's the part I got wrong. Small products go down, everybody knows it. What hurts is when users can't tell if you even noticed.

So here's the small setup I use now. It costs nothing and took one afternoon.

1. Find out before your users do

If a customer is the one telling you the site is down, you've already lost the first 20 minutes.

One external uptime check on the homepage AND one on a real endpoint that touches the database (I use a tiny /health route that runs select 1). The homepage alone lies, it's often cached or static.
Alerts go to my phone as a push notification, not email. Email I see an hour later.
Check every 1–3 minutes, and alert only after 2 failures in a row. Otherwise you get woken up for one flaky request and start ignoring it.

I wrote about doing this while still having a day job in how to monitor a side project during your day job, the short version is: fewer alerts that you actually trust.

2. Have one place to say "we know"

You don't need a fancy status page product. You need one URL that you can update in 30 seconds from your phone, and that does not live on the same server as your app. (Mine was on the same server for a while. Guess how useful that was.)

Options that work fine for tiny products:

a free hosted status page from your uptime tool
a pinned post on whatever social account your users actually follow
a static page on a different host

Then link it from the error page and the footer. My 500 page now literally says "if this keeps happening, check status here" with the link. That one line would have saved me both of those emails.

3. Pre-write the three messages

When something is broken you're stressed and you write badly. So I wrote these once and keep them in a note:

Investigating: "Some people can't load the app right now. I'm looking at it. Next update in 30 minutes or sooner."

Fixed, watching: "It's back up. Cause was X. I'm watching it for the next hour."

After: a short plain email to anyone who was active during the window. What broke, how long, whether any data was affected (say clearly if not), and one thing I changed so it's less likely next time.

Notice the "next update in 30 minutes". Giving a time is the thing that calms people. Then actually post the update, even if it's "still working on it".

4. Check data, not just uptime

The scariest part of my outage wasn't downtime, it was 10 minutes of not knowing if writes during the failover got lost. They didn't, but I couldn't say that confidently until I checked.

If you can't answer "did anyone lose data?" in a few minutes, that's a backup and restore problem, not a status page problem. I went through that drill in a monthly backup restore routine for a solo SaaS, worth doing before you need it.

5. Write a tiny post-mortem, even just for you

Five lines in a doc:

What happened and when (with timezone, future you will forget)
How I found out (alert or customer?)
How long until users could see a status update
Root cause, in one sentence
One change I'm making

Line 3 is the one I watch now. First time it was "never". Now it's under 10 minutes.

What changed after

I've had two smaller incidents since. Both times I got replies like "thanks for the heads up" instead of cancellations. Same kind of downtime, totally different reaction. Turns out people forgive a broken product way faster than a quiet founder.

If you're building in public and want a few early users who are fine with this kind of honesty, launching on a small community board like MakerHunt is where I've found the most patient ones.

How do you handle it when your thing goes down? Do you post a status update, or just fix it and hope nobody noticed? Genuinely curious.

An AI feature on a free plan bills you, not the user. Before shipping mine: hard cap, per-user token quota, per-minute rate limit. Boring, but cheaper. https://dev.to/posting-dude/put-a-meter-on-your-ai-feature-before-someone-else-runs-up-the-bill-df4

Posting Dude — Sat, 10 Oct 2026 06:16:53 +0000

Posting Dude

Oct 10

Put a Meter on Your AI Feature Before Someone Else Runs Up the Bill

#ai #saas #webdev #indiehackers

3 min read

DEV Community: Posting Dude

Your Uptime Monitor Can't See a Dead Cron Job. Heartbeat the 5 Jobs a Tiny SaaS Runs.

1. Write down every job first

2. One check per job, matched to the schedule

3. Ping on success, and ping failure explicitly

4. Add /start to catch hung jobs

5. "It ran" is not "it worked"

6. Platform crons have their own catches

7. Send alerts where you'll actually see them

The 20-minute version

Before You Post a Launch-Day Promo Code in Stripe, Set These 5 Limits

1. Coupon vs promotion code: post the code, not the coupon

2. Pick the duration on purpose

3. Set the four limits before you post

4. The first-time-only trap if you ran a trial

5. Make the code actually usable, then check where it shows up

When launch week is over

Turn On Stripe Customer Portal Before You Hit 50 Customers

1. What to turn on first (minimal config)

2. One "Manage billing" button (not a permanent URL)

3. Deep links for the three emails you already send

4. Webhooks so access matches what they did

5. Traps that show up under 50 customers

why launch days feel empty: makers couldn't see visitors/clicks, so they didn't bring their audience. shipped live maker stats on aura++ https://auraplusplus.com/projects/kai/live?utm_source=devto&utm_medium=social&utm_campaign=bip-aura-maker-live-stats

When a Free Trial Ends and You Have Under 40 Active Trials

1. Know what Stripe actually fires (and when)

2. Card-upfront vs no card: pick one, then set missing_payment_method

3. The emails: three messages, not a drip

4. Access on the day the trial ends

5. A boring checklist before you open trials

6. One product decision this is not

When Someone Asks for a Refund and You Have Under 30 Paying Customers

1. Decide what happens to access before anyone asks

2. Reply once before you refund (unless it's obvious)

3. The Stripe mechanics, as a checklist

4. After the refund, close the loop

5. Make the exit not hurt

Shipped a free AI Visibility Score on Aura++. Ran EarlyHunt first: 53/100, F. Crawlers and on-page both 20/20. AI recall 0/40. https://praneetbrar7.medium.com/my-launch-site-scored-0-40-on-ai-recall-its-seo-checks-were-all-green-546dc57d32f5

Under 100 Payments a Month, One Stripe Dispute Is Already a 1% Dispute Rate

What a dispute costs (US numbers, from Stripe's pricing page)

Prevention first: the three dispute reasons a small SaaS actually sees

Early fraud warnings: refund faster than you think

The webhook gotcha: a dispute doesn't tell you which subscription

When one arrives anyway

Test it before it's real

Stripe Has 8 Subscription Statuses. Your Paywall Probably Checks One.

The 8 statuses, in plain words

What I'd actually do with each one

Store access, not just status

The webhook events that matter

The nightly safety net

A quick test before you trust it

My app was down 40 min once. Nobody complained about the 40 min. They complained that they found zero sign I knew. Now my 500 page links a status page on a different host, and I post "next update in 30 min" even when I have nothing new.

My Tiny SaaS Went Down for 40 Minutes. The Outage Was Fine, the Silence Wasn't.

1. Find out before your users do

2. Have one place to say "we know"

3. Pre-write the three messages

4. Check data, not just uptime

5. Write a tiny post-mortem, even just for you

What changed after

An AI feature on a free plan bills you, not the user. Before shipping mine: hard cap, per-user token quota, per-minute rate limit. Boring, but cheaper. https://dev.to/posting-dude/put-a-meter-on-your-ai-feature-before-someone-else-runs-up-the-bill-df4

Put a Meter on Your AI Feature Before Someone Else Runs Up the Bill

2. Card-upfront vs no card: pick one, then set `missing_payment_method`