Owner only. Every action is checked again by the database.
Loading…
Login throttle is OFF. The KV namespace is not bound to this project,
so the sign-in endpoints are unlimited — which lets someone drain the
project’s email quota (locking you out, and stopping real users getting
a sign-in code) or guess codes. See admin-app/README.md, step 3.
Sign in
A code is only ever sent to the owner address. Any other
address is refused outright — nothing is emailed to it.
Refund revocation has not run in 48 hours.A refunded purchase keeps its Pro plan until it
does. Check the nightly job and the Play notification wiring — see
supabase/functions/play-rtdn.
Signed in as
Database—
Storage—
Full in—
Free-tier headroom
Database used
—
—
The one that causes an outage: at 100% the project goes
read-only and sync stops for every user.
Storage used
—
—
Uploaded files only. If it fills, uploads are refused
and sync keeps working.
Database full in
—
—
Estimate from the last 90 days of growth. It moves as
usage changes.
What happens if a limit is passed
Where the space goes
Who has a copy off their phone
Accounts
—
Everyone registered, including your own test accounts.
With cloud data
—
Their book has reached the server, so it survives a lost phone.
Phone-only
—
Their book exists on the handset and nowhere else. A wipe loses it.
Phone-only means the book exists on the handset and
nowhere else. A lost or wiped phone loses it.
Everyone
Tap a card to list those accounts. Devices and Installs
count things rather than people, so those two open nothing.
Cohorts
Tap a card to list those users.
—
—
Events
Today
—
Entries written since midnight, across all users.
7 days
—
Entries written in the last 7 days.
30 days
—
Entries written in the last 30 days.
All time
—
Every entry ever written. This is what fills the database.
Events per day · 30 days
New accounts per week · 12 weeks
What people do
Devices by platform
App versions in use
Busiest accounts
Who is on what
Tap Free, Pro or Pro Plus to list those accounts.
Founding, Comp and Gross open nothing — the first two are already counted
inside Pro, and the third is money rather than people.
Set a plan
Works for an account that already has a purchase —
use it to grant a HIGHER plan. It can never take a real purchase away:
the buyer's own device keeps whatever Play says they own.
Accounts
Move a purchase to the right account
For a customer who paid but sees
“this purchase belongs to a different account”. Ask them for
the order id on their Google Play receipt.
Record a purchase from a receipt
Last resort, for a customer whose
purchase is not recorded at all (the app says it belongs to a different
account and “Move a purchase” finds nothing). Copy the purchase
token and order id from Play Console → Order management. A refunded
token is refused.
Undo a refund mark
Only when a refund was recorded
wrongly — a chargeback later decided in your favour, or a mistaken
entry. The purchase becomes live again; a NEW refund on the same token
still counts. Both buttons are audited with your reason.
Mark a purchase refunded again
The opposite of the box above,
with its own fields on purpose. Use it when an undo turns out to have
been wrong. The customer loses the plan.
My test accounts
Always Pro Plus by default. Pick a
plan to preview the app as a Free or Pro user; Reset puts it back.
Every change you have made
Append-only. Nothing can edit or
delete these rows — not even you — which is what makes them
worth trusting. Newest first.
Internal address patterns
An account whose email matches
one of these is exempt from Pro, hidden from customer counts and skipped
by the founding backfill. SQL LIKE — % matches anything. Only add a
domain you actually own.