Security

Pulseback wakes people up when production breaks, so it has to be trustworthy on a bad day. This page describes how the service is built and operated. For a security questionnaire, our DPA or a review under NDA, write to security@pulseback.io. Our providers are listed on the subprocessors page.

Infrastructure

• Pulseback runs entirely on Cloudflare’s platform: one Cloudflare Worker serves the API, the dashboard and status pages; Cloudflare D1 stores accounts and workspace data; Durable Objects run the checks (one per check region) and each incident’s escalation; Cloudflare Queues deliver notifications with retries. There are no servers of our own to patch or expose.
• All traffic to pulseback.io, app.pulseback.io and status pages, including custom status-page domains, is HTTPS-only with HSTS. The dashboard sends a strict Content-Security-Policy and refuses to be framed.
• Data in D1 is encrypted at rest by Cloudflare, and the database has point-in-time recovery (Time Travel) for the last 30 days, so it can be restored to any minute in that window.
• Checks run from several regions, and a monitor goes down only when enough regions confirm the failure on a repeat check, so one flaky network path never pages you.

Accounts and access

• Passwords are hashed with PBKDF2-SHA256 and a unique salt per password; we never store them in plain text.
• Sessions are random 256-bit tokens stored only as SHA-256 hashes. Dashboard sessions use an HttpOnly, Secure, SameSite=Lax cookie, and cookie-authenticated changes must come from the app’s own origin. The mobile app keeps its token in the device’s secure storage. Changing your password signs out your other sessions.
• Workspace API keys (pbk_…) are shown once, stored only as hashes, scoped to a single workspace, and can be revoked at any time. The key list shows when each was last used. Email verification, password-reset and invitation links are single-use and stored only as hashes.
• Sign-up, sign-in, password reset and other public forms are rate-limited, and protected against bots with Cloudflare Turnstile.
• Roles (viewer, responder, admin) limit who can change monitors, on-call, billing and integrations.
• Single sign-on with any OpenID Connect identity provider (Okta, Microsoft Entra ID, Google Workspace and others) is available on Business and up, for email domains the workspace has verified.

Your data

• Integration secrets, such as Slack webhook URLs and webhook signing secrets, are encrypted with AES-256-GCM before they are stored, with a key kept as a Worker secret outside the database.
• Outgoing webhooks are signed with HMAC-SHA256 (x-pulseback-signature) so you can verify they came from Pulseback.
• Inbound integration keys (Events API, email, deploy webhooks) and heartbeat URLs can be rotated at any time; the old key stops working.
• Raw check results are deleted after your plan’s retention period; deleting a workspace deletes its data, and backups age out after 30 days.
• AI features (incident summaries and postmortem drafts) send only that incident’s data to Anthropic, through Cloudflare AI Gateway, and only on plans that include them. Nobody trains models on it. See the Privacy Policy.

The alert path

Paging is built to keep working when other parts of Pulseback don’t:

• Each open incident’s escalation runs in its own Durable Object with durable alarms, holding everything it needs, independent of the dashboard and the API database. A minute cron re-arms any escalation that falls behind.
• Every notification has an idempotency key, so retries can’t page the same person twice for the same step, and failed deliveries are retried with exponential backoff; anything that still fails is kept for inspection.
• Every page and message is recorded in the delivery log, with who acknowledged and how.
• We monitor Pulseback with Pulseback, and with an independent watchdog that runs outside our production Cloudflare account and alerts us over separate channels if the app, the check engine or alert delivery stops answering. Our own status is at status.pulseback.io/pulseback.

Payments

Billing is handled by Stripe Checkout and the Stripe Customer Portal. Card details go straight to Stripe; Pulseback never sees or stores card numbers. Stripe webhooks are verified by signature before they change a plan.

How we operate it

• Production access is limited to the people who operate the service and requires multi-factor authentication.
• Changes ship through code review and automated tests, to staging first; production deploys are versioned and can be rolled back in seconds.
• Secrets live in Cloudflare’s encrypted secret store, never in the code or the database.

Reporting a vulnerability

If you believe you’ve found a security issue, email security@pulseback.io with the steps to reproduce it. We’ll acknowledge your report, keep you updated, and credit you if you’d like once it’s fixed.

Please act in good faith:

• Only test against accounts and workspaces you own.
• Don’t access or change other people’s data, and stop as soon as you reach any.
• No denial-of-service, spam, social engineering or physical attacks, and don’t send pages or emails to people who didn’t agree to it.
• Don’t point monitors at systems you don’t own.
• Give us reasonable time to fix the issue before telling anyone else.

If you follow these rules, we consider your research authorized, we won’t pursue or support legal action against you for it, and we’ll work with you to understand and fix the issue quickly.