How we handle your clients' data

Stallguard never writes to a source. For Airtable we ask only for a read scope; for Google Sheets we read a sheet you've shared “anyone with the link can view”; a heartbeat is just an inbound ping you send us. There is no code path in Stallguard that edits, deletes, or adds to your data.

To detect silence we only need to know how much data arrived and how freshit is. So we store the measurement, a row count or the latest timestamp, not your clients' record contents. Rows are counted in memory at check time and discarded.

The data we keep is: your account, your sources (with the access token encrypted, see below), your monitor settings, a history of check results (counts/timestamps and the computed status), incidents, and your alert channels.

All traffic runs over TLS. Source access tokens (e.g. an Airtable personal access token) are encrypted before they touch the database using AES-256-GCM, and decrypted only server-side at check time. They are never sent to the browser.

Every row in our database is scoped to an account and protected by Postgres Row-Level Security. The database itself enforces that you can only read your own account's sources, monitors, and history. This is verified with an isolation test: a request authenticated as a different account returns zero rows.

Sign-in is by emailed magic link. We don't store passwords. Sessions are managed with secure, http-only cookies.

• SupabasePostgres database & authentication
• VercelApplication hosting & scheduled checks
• ResendTransactional & alert email
• StripeSubscription billing (we never see card numbers)

Delete a source or a monitor at any time and its history is removed with it. Close your account and we delete your data. Check history is retained while the monitor exists so you can review past incidents.