DEV Community: SuperLede

I checked 1,000 YouTube channels to see which ones look monetized. Here's what the data says, and what it can't.

SuperLede — Sat, 05 Sep 2026 16:59:36 +0000

In November 2023 YouTube stopped exposing a public flag that said whether a channel was in the Partner Program. Every tool that answered "is this channel monetized" was reading that flag. They all still answer the question. None of them will tell you they're now guessing.

I built one of those tools, so I want to lay out what mine actually reads, where it fails, and what happened when I pointed it at 1,000 channels across 30 countries.

What you can and can't see from outside

"Monetized" means the channel is in the Partner Program. There are two tiers:

Fan funding needs 500 subscribers, 3 public uploads in 90 days, and either 3,000 watch hours in a year or 3M Shorts views in 90 days. It unlocks memberships, Super Thanks and the merch shelf.

Ad revenue needs 1,000 subscribers and either 4,000 watch hours in a year or 10M Shorts views in 90 days.

Watch hours are private. Subscriber count usually isn't. So from outside you can see the eligibility line but not whether the creator applied, got in, or got kicked out later. Anyone quoting an accuracy percentage is quoting a number they have no way to compute.

The five things I read

Every check returns these five as pass, fail or unknown, and the result page shows all five with a sentence each.

Subscriber count, from the official API. It's a clue about eligibility, nothing more. A 40,000-subscriber channel can be unmonetized and a 900-subscriber one can be in the fan funding tier.

The Join button. Memberships are Partner Program only, so if it's there the channel is in. If it's missing that means almost nothing, because plenty of monetized channels never turn memberships on.

Ads on recent long-form uploads. I sample several recent long videos and check whether ads are actually being served. Strongest signal for the ad revenue tier, with a caveat I'll get to.

Merch shelf. Also Partner Program only, also opt-in, also needs a linked store. Present is strong evidence, absent is normal.

The 500-subscriber floor. Below it the channel can't be in the program at all. This is the one signal whose failure is a real negative.

The trap

Since November 2020, YouTube runs ads on videos from channels that are not in the Partner Program. The creator gets nothing from those ads.

So "I saw a pre-roll" proves nothing on its own, and any checker that only looks for ads will confidently call an unmonetized channel monetized. I require ads on at least two thirds of the videos I successfully sampled, and a channel with one lucky pre-roll doesn't clear that.

How the verdict comes out

Evidence has an order. Partner-Program-only features first, then ad delivery, then subscriber counts. Subscriber counts never override a product signal: if a channel shows a Join button at 480 subscribers, the Join button wins.

Four outcomes:

Likely monetized — enough subscribers, memberships on, ads running.
Possibly monetized — one Partner Program feature or the ad signal is there, but the set isn't complete. Usually memberships on, ads not detected.
Likely not monetized — no positive signal at all, and either under 500 subscribers or clearing 1,000 with every readable product signal negative.
Can't tell — the evidence is missing or points both ways. I say so instead of picking.

Two rules that took the longest to get right

Unknown is not fail. A blocked fetch, a hidden subscriber count, a channel with no long-form uploads: none of those are evidence of anything. They stay unknown and never push a verdict toward "not monetized". My first version got this wrong and produced confident false negatives for channels that were merely hard to read.

Failed samples stay out of the denominator. If I try five videos and one loads, "1 of 1 has ads" is not a 100% ad rate, it's a sample of one. Below two successful fetches the ad signal stays unknown.

What 1,000 channels looked like

Guessing about aggregate behaviour is easy, so I measured it. For each of 30 countries I asked the API for the most popular videos right now, took the channels behind them, and checked 35 per country.

Country	Look monetized
Greece, Hungary	51%
Brazil, Romania	49%
France	46%
Germany, Thailand	40%
UK	26%
US	23%
Japan	20%
Korea	9%
India	3%

Two things surprised me. The US is nowhere near the top, despite being the market everyone assumes is most monetized. And the spread is enormous for channels that are all, by construction, big enough to be trending.

I can't fully explain the US number from outside, which is the honest answer. My guess is that US trending skews to music and network content where memberships and merch simply aren't used, but I can't prove that, so it stays a guess in public too.

The other number worth stating: I couldn't tell either way for 18% of channels. That's the number a tool selling certainty would quietly drop.

Full table, method and the CSV are here: https://monetizationkit.com/data/youtube-monetized-channels-by-country/

One engineering note, and a bug worth stealing

The first version read video data from YouTube's internal player endpoint. That's now gated by proof-of-origin tokens for automated callers, so it reads the public watch page instead. Slower, messier, doesn't pretend to be a browser.

The bug I'd point at, because I suspect it's common: I had a rule saying a forced refresh must not overwrite good cached data with a degraded result. Sensible. But it also blocked the very first write for a channel that had never been cached, so every channel whose signals I couldn't read was silently dropped. The dataset could only ever show three of the four verdicts, and it made the tool look more confident than it was. Data that never gets written is much harder to notice than data that's wrong.

The second one, same flavour: my collection run showed ad-fetch failures jumping from 1.2% in the first hour to 30% in the second. I read that as "these channels are unreadable" and nearly published it. It was my own rate limiting. Slowing down and re-running recovered nine in ten. If you scrape for a dataset, plot your failure rate against time before you believe any of it.

What I'd like torn apart

Is there a public signal I'm missing? Super Thanks and Super Chat are Partner Program features too. I surface them where visible but don't score them.
Is one middle tier clearer than two for non-technical creators, or is "possibly" doing too much work?
If you run a channel: does the breakdown match what Studio shows you? That's the only real validation this can get.

The checker is free and needs no login: https://monetizationkit.com/

Supabase Backups Don't Include Your Storage Files. Here's What Does.

SuperLede — Wed, 15 Jul 2026 17:20:39 +0000

The restore finished clean. pg_restore exited 0, every table came back, row counts matched, the app booted. Twenty minutes later the first support message arrived: profile pictures were broken. Then the PDFs. Then every file anyone had ever uploaded.

Nothing about the restore failed. This is how Supabase Storage is built — and it applies equally to the built-in daily backups, to PITR, and to your own pg_dump. None of them include your Storage files.

Your database only stores pointers

Supabase Storage is two systems. The storage.objects table in your Postgres database holds the metadata — bucket, path, timestamps, owner. The actual file bytes live in a separate S3 backend operated by Supabase, entirely outside your database.

Restoring the database restores the pointers. If the files behind them were deleted, or you're restoring into a fresh project, those pointers now reference objects that don't exist. The dangerous part: everything looks healthy from SQL. Row counts match, constraints hold, select count(*) from storage.objects is exactly right — until something requests a file and gets a 404.

Prove it to yourself in five minutes

Ask your database what it thinks is in Storage:

select bucket_id, name, created_at
from storage.objects
order by created_at desc
limit 20;

Now dump your database with pg_dump, restore it into a local Postgres, and run the same query. Every row is there. Not one of the files those rows describe came with the dump. The restore passes every SQL check you can write and still lost your users' data.

Backing the files up

The good news: Supabase exposes the Storage backend over an S3-compatible endpoint, so the files can be copied out like any other bucket.

First, create S3 credentials. Dashboard → Storage → Settings → S3 Access Keys → enable the S3 connection and generate a key pair. The endpoint and region are shown on the same page; the endpoint looks like:

https://<project-ref>.storage.supabase.co/storage/v1/s3

One warning before anything else: these keys bypass RLS. Treat them like a service-role key — server-side only, never in client code.

Option A: DIY with rclone

Sync every bucket to storage you own — Cloudflare R2, Backblaze B2, or your own S3:

# ~/.config/rclone/rclone.conf
[supabase]
type = s3
provider = Other
access_key_id = <SUPABASE_S3_ACCESS_KEY_ID>
secret_access_key = <SUPABASE_S3_SECRET>
endpoint = https://<project-ref>.storage.supabase.co/storage/v1/s3
region = <project-region>

[r2]
type = s3
provider = Cloudflare
access_key_id = <R2_ACCESS_KEY_ID>
secret_access_key = <R2_SECRET>
endpoint = https://<account-id>.r2.cloudflarestorage.com

rclone sync supabase:<bucket> r2:my-backups/storage/<bucket> --checksum

If rclone throws signature errors against the Supabase endpoint (some releases after 1.67.0 did), the plain AWS CLI is a reliable fallback:

aws s3 sync s3://<bucket> ./storage-backup/<bucket> \
  --endpoint-url "https://<project-ref>.storage.supabase.co/storage/v1/s3" \
  --region <project-region>

Two things to get right if you go this route:

Dump the database in the same run. Schedule the rclone sync and the pg_dump together (cron, or a GitHub Actions workflow), so the database snapshot and the file snapshot describe the same moment. Otherwise a restore hands you metadata rows and files that disagree with each other.
Budget for egress. Downloading your files counts as uncached egress on your Supabase bill — $0.09/GB beyond your plan's allowance (Free: 5 GB/month, enforced through a fair-use flow of notice → grace period → restrictions, so recurring large backups aren't viable there; Pro: 250 GB included). For big buckets, weekly beats daily.

Option B: an open-source CLI that does both in one run

Disclosure up front: I'm the author. The backupdrill CLI (MIT, github.com/backupdrill/cli) grew out of exactly the incident at the top of this post. One run streams the pg_dump (custom format) and the Storage files to a bucket you own, and writes a manifest with SHA-256 checksums:

npm install -g backupdrill

export BACKUPDRILL_SUPABASE_STORAGE_ENDPOINT="https://<ref>.storage.supabase.co/storage/v1/s3"
export BACKUPDRILL_SUPABASE_STORAGE_REGION="<project-region>"
export BACKUPDRILL_SUPABASE_STORAGE_ACCESS_KEY_ID="…"
export BACKUPDRILL_SUPABASE_STORAGE_SECRET_ACCESS_KEY="…"

backupdrill backup

You'll also need the database connection string and a destination bucket — the repo covers the full configuration, ships a GitHub Actions template for scheduling, and has an estimate command that projects the egress cost before you commit to a schedule.

The part I actually built it for is backupdrill drill: it restores the latest snapshot into a throwaway Docker Postgres and verifies it — archive checksum, table count against the manifest, populated tables restored non-empty, sampled SHA-256 checks on the Storage files — then destroys the container. Because a backup you've never restored is a guess.

Option C: the hosted version

If you'd rather not babysit cron: BackupDrill runs the same open-source engine on a schedule — database and Storage files captured together into your own bucket, restore drills that prove the snapshot actually comes back, failures emailed. The free plan is one project with weekly backups and includes a restore drill on your first backup, no card.

The takeaway

Whatever you use for the database — built-in backups, PITR at $100 per month, or your own dumps — none of it covers Storage files. If users upload anything you'd mind losing, the files need their own backup path, and the database snapshot and file snapshot need to describe the same moment.

This is an expanded version of a guide originally published on backupdrill.com. I build BackupDrill; the CLI above is MIT and works without the hosted service.