Security
Sched is a small product. This page explains exactly what we access, what we store, and how we protect it — without marketing language.
What Sched never accesses
- ✓No message content. We don't request or call Slack message history APIs. We cannot read your channels or DMs.
- ✓No passwords. Authentication is Slack OAuth only — we never see or store a password.
- ✓No profile data beyond what's necessary. We store Slack user IDs to map rotation assignments. We don't store names, emails, or profile photos.
What we store
Only what's needed to run rotations: rotation schedules, assignment mappings (Slack user IDs ↔ user group IDs), and basic workspace metadata (workspace ID and name).
How we protect it
- —Token rotation. Slack OAuth tokens are managed by Nango and rotated automatically. We never store long-lived tokens in our own database.
- —Encryption in transit and at rest. All traffic uses TLS. Data at rest is encrypted by MongoDB Atlas and Upstash (AES-256).
- —Workspace isolation. Each workspace's data is strictly separated. One tenant cannot access another's data.
- —Least-privilege Slack scopes. We request only the permissions needed: user group lookups, membership updates, and optionally sending notifications.
- —Revoke anytime. Remove the integration from Slack (Settings → Manage Apps → Remove) to immediately stop all access. Email security@getsched.dev to request deletion of stored workspace data.
Sub-processors
| Provider | Purpose | Region |
|---|---|---|
| Vercel | Application hosting | US |
| MongoDB Atlas | Primary database | US |
| Upstash Redis | Caching & rate limiting | US |
| Nango | OAuth token management | US |
| Inngest | Scheduled job execution | US |
Common questions
Report a vulnerability
Email security@getsched.dev. We aim to respond within 48 hours.