Email, batched. Actions, logged.

How Playloop talks to you.

Playloop sends two kinds of email, operational (an analysis finished, a webhook auto-disabled, a tester redeemed your key) and digest (Friday recap). Operational emails route through a per-user opt-out: each one maps to one of the four toggles on Settings → Notifications. An explicit false on that toggle wins; a missing value defaults to TRUE so new accounts opt INTO email without an onboarding click.

The same Settings page has an Audit log tab, a newest-first feed of every security-relevant action recorded against your account: sign-ins, key rotations, BYO AI key writes, webhook URL changes, step-up MFA, account-close attempts. If you see something you don’t recognize, that’s the first stop.

The four toggles.

Each toggle controls one class of email. Every email footer links back to Settings → Notifications so the opt-out is always one click from any inbox.

How the gate works

Before Playloop sends any operational email, it checks your saved preference for that class:

• Toggle explicitly off → skip the email.
• Toggle explicitly on → send.
• Never set → default ON (new accounts opt in by default).
• Lookup fails → permissive direction. We’d rather send a possibly-security-relevant email twice than drop one because a read flaked.

When you save the form, the change is recorded in your audit log so a later “wait, did I turn that off?” question has an answer.

The 13-minute analysis-finished bundle.

Upload ten sessions in a row and you’d expect ten emails. You don’t get them. When AI extraction finishes on a session, Playloop doesn’t email immediately, it queues the notification and lets a background bundler collapse the burst into a single email.

Timing

• 13-minute dispatch threshold. You get a bundled email within roughly 13 minutes of the first session in a burst — long enough for a back-to-back run of analyses to collapse into one email, short enough to still feel timely.
• One email per burst. A burst of 10 analyses queued back-to-back lands as a single email, not ten.

What the email looks like

The shape depends on how many sessions ended up in the bundle when the sweep flushed.

Concurrency and failure

• Once-only dispatch. Two overlapping bundler passes can’t dispatch the same bundle twice, the second pass finds the bundle already marked sent and skips it.
• No retry on dispatch failure. If the email provider rejects the send, the bundle stays marked sent. We don’t retry, re-attempting risks double-sending to users whose first attempt actually delivered. Instead, the failure shows up in your audit log.
• Per-pass cap: 100 user-bundles. A single user can have at most one bundle waiting at any time given the threshold, so 100 covers ~30x current daily user volume before we’d need a higher cap.

Friday recap with week-over-week deltas.

The weekly digest ships every Friday at 14:00 UTC. Europe sees it in the afternoon, US Pacific sees it before they sit down. One global slot, not per-timezone scheduling.

Who gets the email

A user gets the Friday digest when both of these are true:

• The Weekly digest toggle is on (default).
• The account has at least one session in the trailing 7 days. Inactive accounts get nothing, there’s no recap to send, and emailing “0 sessions, 0 testers” reads as spam.

What’s in it

Five lines, intentionally bland, neutral activity report, not a dashboard. If you want real insight, the CTA takes you to the live dashboard.

• Sessions, count this window.
• Testers, unique devices that played this window.
• Insights extracted, insights generated during the window.
• Most-active game, the game with the most sessions this window.
• Top friction tag, reserved; v1 leaves this off rather than ship a misleading line on noisy weeks.

Week-over-week delta chips

Each numeric stat shows a small delta next to its value. The prior window is the 7 days immediately before the current one, same length, like-for-like.

Math: round((current - prior) / prior * 100), clamped to integer percent so the chip stays compact. The four cases the digest covers:

Safety rails

• 500 users / run. Runaway-protection rail. Real usage is well below that today; if it’s ever exceeded, the run logs it so ops sees the volume scaling.
• No retries. A failed send is logged in your audit log; we don’t resend.
• UTC date label. The subject reads e.g. May 12–May 18 in UTC regardless of where the recipient lives.

Settings → Audit log.

Every notable security event on your account writes one row to your audit log. The Audit log tab renders these newest-first, 50 at a time, with offset pagination.

What the UI shows you

Each row renders a short description, a severity dot (green / amber / red), the relative time, and a sorted key/value list of supporting details. Two display rules matter:

• Area + operation are promoted to the front. Areais a human-readable label (“Account & Security”, “API Keys”, “AI Provider”, “Integrations”). Operationis a short verb that names what you did. Those two together answer “what part of the app + what did I do?” faster than any other field.
• Internal identifiers are hidden. You already know who you are, and raw URLs are noise once an area label exists.

What gets logged

Playloop only logs from a fixed allowlist of events, there’s no free-form logging surface. The user-relevant categories are:

Step-up reverification

An entry lands every time you hit a step-up gate and Playloop opens the reverification modal. The supporting details name the area, the operation, and the level of proof that was asked for, so you can see exactly which sensitive action triggered the extra factor.

Sensitive settings writes

These actions each write a row when they succeed:

• API key rotations , one row when you rotate the ingest or management key, and a warn-severity row when you rotate both at once. The supporting detail names which scope and which new version.
• BYOK key saves and clears , one row per save or clear, naming the provider and the masked tail of the key (e.g. …7f2a) so you can reconstruct rotation history at a glance.
• Monthly cap changes , one row per cap change, with the prior and new monthly budget in cents (so the trail reads “$25 → $50”, not just “$50”).
• Studio profile + notification preference edits , one row per save. The notifications row carries the diff of what changed.
• Identity changes , password set, password changed, TOTP enrolled, TOTP disabled (warn), backup codes regenerated, OAuth provider connected, OAuth provider disconnected (warn), primary email changed. Each row names the provider or device involved.
• Session revocations , one row when you sign a specific device out, a warn-severity row when you use “Sign out everywhere.” The supporting detail names the device + browser or the count of sessions revoked.

How the entries get there

Two paths write into the log, and the difference matters when you’re debugging a missing entry:

• Server-side ops (rotating an API key, saving a BYOK key, editing notifications, promoting a verified new email to your primary address) write the audit entry automatically when the action lands. You only see the resulting row.
• Client-side identity ops (password change, TOTP enroll, OAuth connect / disconnect, per-device sign-out, sign-out-everywhere) happen through the authentication provider’s SDK directly in the browser. After each successful mutation the client posts a closing event so the entry still lands in your audit log. The server validates the event against the same allowlist as server-side ops, a hostile client can't forge entries for other users or invent new event types.

System events you might see

Past the “you took an action” rows, a few system entries show up on a healthy account: an account-created anchor (your “day I joined” row), one row per successful sign-in (password, OAuth, magic link, not one per token refresh), one row per session end, one row per Playloop-sent email (welcome, analysis-finished bundle, weekly digest, webhook disabled, tester redeemed), and a warn-severity row when an email send is rejected by the provider.

Where each lever lives.

If you know what you want to change, this is the fastest way to find it.