Counts across every team, not one. Press a figure to open the section that governs it. A figure that has not arrived yet shows — rather than nought — a zero that means “not loaded” cannot be told from one that means “none”.
Composed from what this database actually records: teams, boards and accounts as they are created, System Admin role changes, and retention runs. Several kinds of administrative change are recorded nowhere at all — the Audit section names them, so a quiet list is never mistaken for a quiet system.
The application-wide switches as they stand right now, read back from the database rather than from what this page last wrote. Off is not a warning: a deliberately quiet system is a correct one. A row is marked only where a setting’s own values contradict each other — switched on, and configured so that nothing can actually be checked.
Inactivation and deletion are server-authorized operations with dependency checks, confirmation, audit, and deterministic recovery.
Every objective in the application is a cleanup candidate. Candidate status is not proof that deletion is safe — every dependency is re-checked inside the authorized server transaction immediately before anything is removed.
Candidate classification and destructive mutation are separate operations.
Notifies, then permanently deletes, accounts that have gone dormant. Their shared tasks, notes, boards and objectives are handed to another owner first, and every deletion is kept in the audit view below.
Idleness here is measured from each account's last sign-in, which only means what it says because sessions themselves now expire after 48 hours. A first-notice threshold has to clear that margin, or it would be measuring a session that is merely still open rather than an account that has gone quiet — the database refuses a setting that does not.
Every account in the application, with its team, its roles and when it was last seen. Filter by team, narrow to system administrators or dormant accounts, and select rows to activate, deactivate or delete them.
Every account this feature has permanently deleted, what was transferred and to whom, and whether the deletion completed cleanly. Metadata only — nothing that was deleted is kept here.
Applies to new accounts and password changes made through the sign-in page. Each level includes everything the level below requires.
The largest single file anybody may attach. Storage refuses a bigger upload itself, so this is the rule and not a suggestion, and it takes effect the moment it is saved. Files already stored above a new, lower limit are unaffected and stay downloadable — the size is checked when something is added, never afterwards.
A System Admin can open this console, read and change every account, administer every team and board, and permanently purge team content and files. A Team Admin is a different and much narrower role — it grants authority inside one team only. Grant or revoke this from an account's Profile in the People tab.
Every grant and revoke, with who made it. Metadata only — nothing about credentials is recorded here.
Which teams may send, and which events they send. A team ships off and stays off until somebody turns it on here or in the team's own settings — the two write the same columns and always agree. The Application email switch still outranks every row here: while it is off, nothing here sends.
Every delivery the application has attempted, and what became of it — the event, who it was for, the address it actually went to, and why it stopped if it did. Suppressed is not failed: a suppression is the system deciding not to send, and it is counted separately everywhere on this block. Only a genuine delivery failure can be selected and tried again. Retry puts messages on a queue and Send queued is what actually delivers them — two acts, two controls, and the second one reaches real inboxes. The sender re-runs every gate it ran the first time, so a message a switch now stops is suppressed rather than sent.
Whether the application may send notification email at all. Turning this off stops every mention, assignment, share and ownership email across every team — the Message Center carries on exactly as it is. Signing in, password resets and other account email are not affected by this switch and continue whatever it is set to.
Try a notification before switching it on for anybody. Nothing here changes a setting, and it can only ever send to the addresses on your own account.
Which notification to try.
The real template, with sample content and a banner a real notification does not carry.
Which of your own addresses receives it — there is no recipient field, deliberately, and it cannot name a new one. Default follows this event’s own routing and names the address it lands on.
Send to me delivers what the preview shows, even while the switch above is off.
Walks the same gates the sender walks and reports where it would stop.
Team narrows the switches checked; Recipient is the person the gates are read for.
Trace sends nothing, records nothing and reveals no addresses.
How outbound notification email is folded into fewer messages, and how repeated Message Center updates about the same subject are folded into one — every batch below, with the reason the model or the deterministic fallback gave for it. Suppression is recorded before it is acted on: while that switch is off, a “not materially new” verdict is written down and the message still goes out — this section is where those verdicts are read before anybody is trusted with silence.
Turning consolidation off still delivers whatever is already queued, one message at a time, rather than losing it. Suppression and Message Center folding both ship off so a week of the model’s judgments can be read in the lists below before either is trusted with silence. Asking the model off falls back to the same deterministic rule a missing credential or a run over its call budget already uses.
Choose which teams may use Tasks by Email. Access requires the application switch, an enabled team membership, and the member's own configured AI Assistant. Created tasks always remain personal.
Every received message and the outcome of sender matching, feature gates, AI processing, task creation, retry, and suppression. Sensitive addresses stay masked and message bodies are never shown.
| Select | Received | Sender match | Organization / team | Source | Result | Task / evidence |
|---|
Controls email-to-task processing only. Outbound notifications are unchanged.
STRIDE
—
Test eligibility, identity resolution, AI extraction, and personal-task creation using your own account — never another user's.
Each of these is a page somebody with no account can open, and each is independent of the others. While the switch below is off none of them is challenged, whatever these say.
Cloudflare Turnstile puts a challenge in front of the pages anybody can reach without signing in. It is off until it is switched on here, and while it is off the flows above behave exactly as they always have. Signing in with a correct password is never challenged — only the three flows named above.
The public half of the pair, from the Turnstile widget in your Cloudflare dashboard. Every visitor’s browser is served it by design, so it is not a secret and showing it here reveals nothing that is not already on the wire.
Nothing on this page can check that this is the right key, and no check below does either — Cloudflare offers no way to verify a site key from a server. A wrong one fails silently and distinctively: the challenge simply never appears, and everybody on a challenged flow is asked to complete a check that is not on screen. If verification is switched on and nothing seems to happen, compare this character for character with the Cloudflare dashboard before looking anywhere else.
The private half. It is written and never read back — this field submits and clears, the database answers only whether a secret is present, and nothing on this page can display, echo or partially reveal it. If it has been lost, roll a new one in Cloudflare and save that; there is no way to recover this one from here, deliberately.
Asks Cloudflare directly, with a token that is meant to be refused, and reports what came back. Stored is not the same as working — a secret that Cloudflare rejects leaves human verification switched on and verifying nothing. Nothing is sent, saved or changed by this check.
It answers about the secret and nothing else. The token it sends is meant to be refused, so the site key is exercised at no point — a green answer here is entirely compatible with a wrong site key and a feature that does not work. Whether the pair actually challenges anybody can only be established in a browser, on the sign-in page.
Visualize. Explore. Manage. Keep the footprint intentional.
Select a tile to filter. Area is total storage.
Attachment bytes are exact. Everything else is an estimate of row content — deleting rows makes that space reusable inside Postgres, it does not shrink the database file.
Select a bar to filter by age range.
Select a type to filter.
Every task is counted, not just the ones on a board. An individual task is reported under its owner’s default team, or their first team if they have set none. People who belong to no team appear under No Team / Personal. Where a task is reported never decides what a purge deletes: a team’s policy only ever removes content that reaches it through a board it is actually on.
Supabase capacity here is deliberately small, so this page exists to keep the footprint intentional. Exact and estimated are marked on every figure. These totals are application-wide and do not change when a filter is applied.
Teams and personal footprints in one ranked list, each with a next step that configures and previews rather than deleting. Personal rows are aggregated — a name, a count and a size, never the contents of somebody’s private tasks.
Any whole number of days from 1 to 3650. The presets are shortcuts; the number you type is what counts.
Every team has a policy from the moment it is created: closed content older than 180 days, evaluated daily. It runs in the database on a schedule, not in a browser. Open work is never purged automatically unless you change what this applies to.
Preview first, always. Nothing on any chart, card or table can delete anything; this is the only path, and it ends in a typed confirmation.
Two kinds of number, and they are not the same promise. Attachment bytes are exact and leave Supabase Storage when the file is removed. Row content is an estimate of what the rows hold, and deleting them makes that space reusable inside Postgres rather than handing it back — the relation does not shrink. Neither figure is presented as the other.
Row content per data class beside the physical relation and index bytes those rows sit in. Some of the largest classes are never purgeable — profiles and personal notes among them — and are shown so the picture is complete rather than to invite action. Reported only: nothing here runs a VACUUM.
Postgres cannot delete a Storage object, so a purge queues the paths before it deletes the rows that name them and this console drains the queue. A run stays partial until its files are gone, which is honest rather than tidy. Removing queued files is deliberate: it never happens on its own.
Closing an organization records its brand files rather than deleting them — removing the Storage row would strand the file with nothing naming it. This removes both halves, and only for organizations that are already gone. It never runs on its own.
Rows and files belonging to accounts that no longer exist — left behind by deletions made before accounts were removed in full, or by accounts deleted straight from the Supabase dashboard. They are invisible everywhere else in this console but still occupy the tables and the storage bucket. Scanning and cleaning up are two separate steps, and only proven orphans are ever swept.
Every run, manual or scheduled, with what it removed and what failed. Metadata only — nothing that was deleted is kept here.
See who is using the system, what they are doing, and how activity trends over time.
Every administrative change this application records, newest first. Metadata only — nothing that was deleted or changed is kept here, and a role record stays readable after the account it describes has gone.
Role changes are retained indefinitely. Every System Admin and God Mode grant or revoke is exempt from automatic deletion — not subject to any retention period, configurable or otherwise — because it is the only record this application keeps that a privilege was ever granted. Retention run history is exempt for the same reason: it is the record of what an earlier purge did.
These changes leave no trace in the database, so their absence from the list above means nothing either way. Keeping this list honest matters more than making it short: an administrator reconciling an account of events needs to know which silences are real.