Monitoring needs metadata, not your data.

What we store

• Workflow names and ids, and whether you monitor them.
• Execution statuses, timestamps, and hourly aggregate counts.
• Error messages - scrubbed before storage (see “What we scrub” below).
• Instance labels, URLs, health states, and observed n8n versions.
• Outcome Contract observations as aggregate-only measurements: metric key, time window, observed/expected values, rejected count, quality score, and optional proof link/hash.
• Your account email and billing state.

What we never store

• Execution payloads. Never. The data flowing through your workflows - customer records, messages, invoices - is not persisted on our side. We read execution metadata to detect failures; the payload itself never lands in our database.
• Plaintext API keys, ingest tokens, or webhook secrets (details below).
• Outcome records, prompts, workflow payloads, downstream responses, or proof bodies.
• Card or payment details - checkout is handled entirely by Dodo Payments.

Your n8n API key, honestly

This API key grants broad access to your n8n instance. We only ever call: GET /api/v1/workflows, GET /api/v1/executions, GET /api/v1/executions/:id, and GET /healthz. Prefer not to share a key? Use push-only mode - we never connect to your instance at all.

All four calls are read-only. GET /api/v1/executions/:idis fetched to extract an execution’s error message, which is scrubbed and truncated before storage - the execution’s data payload is discarded, never persisted.

How secrets are protected

• Instance API keys are encrypted at rest with AES-256-GCM and decrypted only in the background worker at poll time. The web application cannot decrypt them, ever.
• Ingest tokens (wfp_ing_…) are shown to you exactly once, then stored only as salted digests, scoped to the endpoint they may call. We can verify a token; we cannot read it back.
• Outbound webhook secrets and token digests are never returned to the browser.
• Application logs scrub token-shaped values and secret-bearing fields before anything is written.

What we scrub

Before any error message is stored, it passes through redaction that removes:

• Email addresses (replaced with [EMAIL]).
• Bearer credentials and JWTs.
• Long hex and base64 strings - the shape of API keys and secrets (32+ hex chars, 40+ base64 chars).
• Our own ingest-token format.

The result is hard-capped at 2 KB. Enough context to debug, not enough to leak.

Tenant isolation

Every query is scoped to your organization in the service layer - not filtered afterwards in the UI. A request for another tenant’s resource behaves as if that resource does not exist. Public endpoints are rate-limited, and customer-supplied URLs (instance addresses, outbound webhooks) go through an SSRF-safe outbound path that refuses private-network targets in production.

Version and advisory data

Vulnerable-version alerts come from published n8n security advisories synced from GitHub, and every alert links its source advisory. We only match versions we can actually observe: the Reporter workflow reports your version in push mode, while the n8n public API does not expose it. When we can’t see a version, it is shown as unknown - not guessed.

Infrastructure and uptime

WorkflowPulse runs on Railway with Postgres; the worker that watches your instances is itself watched by an external heartbeat service. We monitor WorkflowPulse with independent external checks and publish our uptime.

Reporting a vulnerability

Found something? Email security@workflowpulse.dev. You will get a human reply, an honest assessment, and credit if you want it.

Data processing

Subprocessors: Railway (hosting), Resend (email), Dodo Payments (billing), Sentry (error monitoring), PostHog (product analytics). We’ll sign a DPA with Agency-tier customers who require one. Deletion requests: email us and we delete your organization and everything under it.