What does playabilityStatus=LOGIN_REQUIRED mean?

It means YouTube is requiring sign-in for playback in that request context. In many cases the page can still load (HTTP 200) while playback is gated, sometimes accompanied by the UI message “Sign in to confirm you’re not a bot.”

Is this checklist providing a bypass?

No. It focuses on verification: confirming what YouTube serves, collecting receipts, and checking whether the behavior changes over time or across endpoints.

Why test both www and m.youtube.com?

Because availability can differ by endpoint. A video might appear gated on m.youtube.com but not on www.youtube.com (or vice versa), and the state can flip temporarily.

What evidence is most useful for debugging?

Two OS-level screenshots taken ~15+ seconds apart with the URL bar visible and the player progress/time clearly advancing, plus a receipt-style curl probe (bytes + sha256) showing playabilityStatus and reason.

What if GitLab Pages returns a soft-404 while I’m trying to view these notes?

Use the repo “raw” fallback links documented in the Soft-404 Survival Kit; they serve the exact file bytes even when Pages briefly masks it with a tiny “This page could not be found” stub.

YouTube "Sign in to confirm you're not a bot" (LOGIN_REQUIRED)

Copy/paste scripts

If you want to reproduce the monitoring + alert + optional autocapture setup, the scripts are published here:

youtube-pass-checks/tools/youtube_playability (GitLab)

Raw README: README.md

Example receipts (NOT-PASS)

Concrete example from a logged-out/incognito capture:

m.youtube.com shows “Video unavailable” (qq15at0yfYM) (screenshots + SHA-256)

What you’re likely seeing

A YouTube watch page loads, but playback is blocked while logged out.
The UI may say: “Sign in to confirm you’re not a bot”.
In JSON, this commonly corresponds to playabilityStatus=LOGIN_REQUIRED.

How to confirm (fast)

Run the reproducible curl probe and record the result as a receipt:
- Probe page (HTML)
- Probe page (alias URL)
If you can reproduce it in a browser, capture evidence as two OS-level screenshots (URL bar visible) taken ~15+ seconds apart, with player time/progress clearly advancing (or clearly not advancing).

Creator note: If you’re a creator, test both www and m in a fresh logged‑out profile.

Viewer checklist (no bypass; just sanity checks)

Try the same link later (gates sometimes change over time).
Try another network (home vs mobile hotspot) to see if behavior is network/edge dependent.
Try another device or browser profile (fresh logged‑out profile is the cleanest test).
If a companion hub page is unreachable, use raw fallbacks from the Soft‑404 Survival Kit.

If the video is yours, prioritize the “creator/engineer checklist” below — it produces higher-quality receipts.

Creator / engineer checklist (useful for debugging)

Capture the status: record playabilityStatus + reason via the probe.
Compare endpoints: test both:
- https://www.youtube.com/watch?v=VIDEO_ID
- https://m.youtube.com/watch?v=VIDEO_ID
Record OS-level playback proof: two screenshots ≥15s apart showing the URL bar and the player time/progress changing (or not changing).
Bundle receipts: if you’re collecting multiple artifacts, use receipt bundles (hashes + verification commands).
Don’t over-interpret HTTP 200: the page can return 200 while playback is gated; rely on playabilityStatus and UI evidence.

YouTube “Sign in to confirm you’re not a bot” (LOGIN_REQUIRED) — checklist

Monitoring + strict playback receipts

Copy/paste scripts

Example receipts (NOT-PASS)

What you’re likely seeing

How to confirm (fast)

Viewer checklist (no bypass; just sanity checks)

Creator / engineer checklist (useful for debugging)

Related hub pages