Privacy Policy

This policy describes what InBrief collects, and why.

What we store

• Account data: your email address (used for sign-in links and service notices) and your plan state.
• Configuration: the monitors, languages, branding and incident content you enter.
• Monitoring results: HTTP status codes and response times of the endpoints you configure. Response bodies are never stored.
• Subscribers: email addresses, confirmation state, language and service preferences, and subscription and delivery records used to send requested updates.
• Notification destinations: channel settings and encrypted credentials, such as webhook URLs or bot tokens, used to deliver updates to destinations you configure.
• Internal analytics: reporter identifiers, names, region and team metadata, reporting timestamps, aggregated request counts and latency, and error-message samples you send through the Event API. Avoid sending personal data or secrets in error messages.
• External event storage: encrypted warehouse credentials and local reporter metadata remain in InBrief when event history is stored in your warehouse. Failed writes may be buffered locally as aggregated batches.
• Restricted notification previews: enabled WhatsApp previews store recipient names, phone numbers, verification and delivery records. Browser-push previews store subscription endpoints, encryption keys and preferences. These previews are not enabled for general Cloud use.
• Billing: handled entirely by Paddle (merchant of record). We never see or store card details, only Paddle's customer and subscription identifiers.

What we do not do

• No advertising, no selling of data, no third-party analytics on status pages.
• No passwords: sign-in is by one-time email link.

Processors

Infrastructure, including the database, runs on managed cloud hosting we operate. Emails are sent via Resend. Payments run on Paddle. AI translation requests are processed by a third-party model provider, with an automatic failover to a second provider when one is configured; only the incident or monitor text you wrote is sent, and no provider trains on API data.

Visitors to status pages

When aggregate status-page analytics is enabled, a public page sets one host-only, HttpOnly, SameSite=Lax cookie containing only the current UTC day. It expires at the next UTC day and is used only to count one browser once per page per day. Aggregate counts are retained for 90 days. No visitor identifier or IP address is retained, no browser fingerprint is created, and no third-party analytics runs on the page. A visitor's browser may cache page data locally (localStorage) purely to show the last known state when offline.

Retention and deletion

Raw check results are deleted after 90 days; monitoring daily uptime aggregates are kept for the life of the account. Internal event history in InBrief storage is retained for 14 days. Reporter metadata has no automatic expiry. Warehouse history follows your warehouse retention settings. The local external-delivery buffer holds at most 2,000 batches per status page, stops retrying after 50 failed attempts, and makes exhausted batches eligible for deletion seven days after creation. Switching back to InBrief storage discards pending external batches. Deleting your account removes all stored data. Requests: legal@inbrief.sh.

Changes to this document

We may update this document. A material change is announced by email to account holders at least 30 days before it takes effect, and the effective date is shown at the top of this page. Until that date the previous version applies. If you do not agree with a change, cancel your subscription or delete your account before it takes effect; continuing to use the service after that date means you accept it.

Three kinds of change take effect on publication, without notice: changes required by law or a regulator, changes that only benefit you (a lower price, a longer refund window, more rights, a new feature), and corrections to wording that do not change the meaning.

Contact: legal@inbrief.sh