What we store, for how long, and who else sees it.
PullPulse holds review metadata: who opened what, who is waiting on it, and what it touched. It does not hold your source code. This page lists each category of data, the window it is kept for, and every other company that processes it.
Last updated 8 September 2026.
What we store
| category | what it is |
|---|---|
| Slack workspace and user ids | Workspace id and name, the id of whoever installed the app, and the Slack user ids of members who linked a GitHub login, with their timezone and any snooze they set. |
| Sealed credentials | The Slack bot token and, if you configure one, your model provider API key. Both are stored encrypted, and MCP tokens are stored only as a one-way hash, so the token itself is never on disk. |
| GitHub installation and repository metadata | The installation and the account it belongs to, and for each repository you select: its name, default branch, whether it is private, your .pullpulse.yml and the CODEOWNERS file we read to work out who knows the code. |
| Commit authors | The GitHub login, account id and date of the newest commit per person per watched repository, read from the default branch once a day to count committers against the plan. |
| Pull request titles and metadata | Title, description, URL, author and whether that author is an agent, state, reviewers, check results, line and file counts, the computed effort tier and attention flags, diagrams, and the model-written brief where one was generated. PR history remains available after merge or closure without automatic expiry, subject to workspace access and explicit data deletion. |
| Slack message bookkeeping | Which channel and which message belongs to which pull request, so PullPulse can update a message instead of reposting it. Message text is not stored; it is rendered from the metadata above. |
| Notification history | Who was mentioned or reminded, and when. This is what the per-person noise cap is computed from, and what stops a reminder from repeating itself. |
| Failed webhook deliveries | A GitHub webhook that could not be processed, held in a queue so it can be retried after a fix instead of lost. Webhooks that were processed are not stored. |
| Billing records | Your plan and status, the identifiers Stripe gives us for your customer and subscription, period end dates, and a monthly count of model calls. Card details never reach PullPulse. |
| Product analytics and acquisition | Page paths, campaign labels and referrer hostnames, a random browser identifier, workspace, user and channel ids, lifecycle events, and invoice and refund amounts by currency. We use these to understand usage and which sources lead to paid workspaces. We do not send message text, repository names, credentials or full query strings to analytics. |
| Feedback and search index | Thumbs up or down on AI output with the Slack user who gave it, and a search index over pull request titles and descriptions used to find similar past changes. |
| Browser sign-in | Your Slack workspace and user ids, and a secure session cookie for signing in to the website. Sessions expire after 12 hours and are revoked when you sign out. Expired records are removed on the hourly cleanup or the next sign-in. We do not store the Slack user access token from sign-in. |
| Short-lived cache | Access tokens, user lookups and single-use sign-in nonces, each expiring within minutes. |
Diff content is never persisted and never logged. It exists in memory while a pull request is being scored, and in the prompt sent to the model provider for the features that need one. Nothing writes it to storage or to a log line.
Card details never reach us. Checkout and the billing portal are hosted by Stripe; we store customer and subscription identifiers, plus invoice and refund amounts for billing analytics.
Website analytics
When analytics is enabled, a signed first-party cookie remembers a random browser identifier for up to 90 days. Page requests honor Do Not Track and Global Privacy Control. A small first-party script records page views and link clicks; the website works when it is blocked. We keep a bounded event journal for 30 days. Browser records expire after 90 days of inactivity; acquisition attached to a workspace and invoice and refund records remain with its billing history. Vemetric receives the bounded event metadata described above. We forward a bounded browser user-agent for device statistics and referrer origins, but never your IP address, full query strings, form values or message text.
How long we keep it
- Notification history: 7 days. Older rows cannot affect any noise cap, so they are deleted on a rolling sweep.
- Failed webhook deliveries: 14 days. A delivery that fails is kept in a queue for at most 14 days so it can be retried, then expires. Webhook bodies are otherwise never stored; one waiting to be processed stays in a queue for at most four days.
- Commit authors: 30 days, rolling. The census reads the last 30 days of the default branch each time it runs, so a person's row ages out on its own once they stop committing.
- Everything else: the life of the installation. Pull request metadata, routes, identities and billing records are kept while the workspace exists, because they are what the product reads to work.
Who else processes it
- Cloudflare — the whole service is hosted there, including storage and, by default, the model that writes briefs (Workers AI).
- Slack — the surface PullPulse posts to, and the identity provider for everyone using it.
- GitHub — the source of every event and the API we read repository metadata from.
- Stripe — payments, invoices and the billing portal. Stripe is the only sub-processor that sees payment details, and it sees them directly rather than through us.
- Vemetric — website and product analytics, acquisition sources, and payment conversion events. It receives ids and bounded event properties, not source code or payment card details.
- Better Stack — availability monitoring and sampled operational timings stored in the United States. These measurements exclude repository content, account identifiers and request bodies.
- Your chosen model provider — Workers AI by default, which keeps model calls inside Cloudflare. A workspace may instead configure its own OpenAI or Anthropic key in App Home, in which case prompts go to that provider under your account and your agreement with them.
How it is protected
- Every stored credential is encrypted at rest with a key that is specific to your workspace, so one workspace's secrets cannot be read through another's.
- Every inbound request from GitHub and Slack is verified as genuinely theirs before it is processed. An unverified request is rejected, not logged and retried.
- The status page you reach after installing is not addressable by workspace id. It opens only from a signed, expiring link that Slack itself hands you, so a URL is not a way to read a workspace you are not in.
- MCP tokens are stored as hashes, scoped to one workspace, and revocable from Slack.
- Logs carry only the fields the code explicitly names, with secrets redacted. Repository content and credentials are never among them.
- Every read and write is scoped to one Slack workspace, and that isolation is covered by tests rather than by convention.
Deletion
Uninstalling the app from Slack revokes the stored credentials immediately and stops all processing for that workspace. The rows survive the uninstall so that reinstalling restores your routing, identities and history rather than starting from nothing, and so that uninstalling and reinstalling cannot mint a fresh trial.
Ask us to delete the workspace and we delete it, completely rather than best-effort; failed webhook deliveries expire from their queue within 14 days.
Contact
For access, correction or deletion requests: support@pullpulse.dev.