Rather than asking you to upload application logs, customer databases, or sensitive business records, CriticalBuzzer is designed to monitor operational signals. In most cases, that's all it needs to detect problems early.


Monitoring Shouldn't Require Your Customer Data

Many monitoring platforms encourage sending large amounts of data "just in case."

We take the opposite approach.

CriticalBuzzer is designed to help you detect incidents using operational signals such as:

  • API response times
  • Error rates
  • Queue depth
  • CPU and memory usage
  • User signups
  • Payment failures
  • Business metrics you choose to send

In most cases, **customer names, email addresses, passwords, payment information, documents, and business records are unnecessary** for reliable monitoring.

**The best way to protect sensitive data is to avoid collecting it in

the first place.**


You Decide Exactly What Gets Sent

CriticalBuzzer accepts any JSON. There is no mandatory schema and no SDK requirement.

That flexibility means you remain in control of every payload your application sends.

Instead of this:

` json { "customer_email":"john@example.com", "credit_card":"4111...", "address":"..." }

code
Send this:

json { "payment_failures":12, "checkoutlatencyms":4200, "affected_region":"US-East" }

code
Or instead of sending customer registrations:

json { "registrationslast5_minutes":18 }

code
The platform needs **signals**, not customer identities.

------------------------------------------------------------------------

## Data Minimization Is a Security Feature

Every unnecessary field increases risk.

Whenever possible, we recommend sending counts, durations, percentages,
health checks, and aggregate business metrics instead of raw customer
information.

### We recommend **never** sending:

-   ❌ Passwords
-   ❌ API Keys
-   ❌ JWT Secrets
-   ❌ OAuth Tokens
-   ❌ Database Credentials
-   ❌ Credit Card Information
-   ❌ Personally Identifiable Information (PII)
-   ❌ Private Keys

If your monitoring can be achieved with summaries instead of sensitive
records, summaries are almost always the better choice.

------------------------------------------------------------------------

## AI Is Optional---Not the Foundation

A common question is:

> **"Will my production data be sent to AI models?"**

CriticalBuzzer is intentionally designed so AI is **not** required for
normal monitoring.

The processing philosophy is:

text Incoming Event │ ▼ Deterministic Rules │ ▼ Anomaly Detection │ ▼ AI Evaluation (only when additional reasoning adds value) │ ▼ Decision Engine `

Whenever deterministic logic can make the decision, it does.

AI is intended for higher-value reasoning---not for processing every event.


Designed to Reduce Your Exposure

The platform architecture follows a simple principle:

Your Application │ ▼ Only Operational Signals │ ▼ CriticalBuzzer │ ▼ Early Warning

Not:

Entire Database Entire Logs Customer Records Sensitive Documents

Less information transferred means less information requiring protection.


Security Built into the Architecture

CriticalBuzzer's architecture incorporates multiple security-focused design decisions, including:

  • Per-alert secret endpoints
  • Strongly hashed API keys
  • Encrypted integration configuration
  • Multi-tenant organization isolation
  • Scoped MCP tokens
  • Token rotation
  • Audit logging for MCP activity
  • Rate limiting
  • Strict JSON validation
  • Secure handling of AI context by excluding secrets and unnecessary
  • data whenever possible

These controls are intended to reduce risk while keeping the product simple to integrate.


Your Data, Your Control

We believe customers should always understand:

  • what data is stored
  • why it is stored
  • how it is used
  • how long it is retained
  • how it can be removed

Monitoring platforms should never feel like black boxes.

Transparency is part of the product.


Security Starts Before Encryption

Encryption matters.

Access control matters.

Audit logs matter.

But the strongest protection often happens before any of those.

Every field you never transmit is one less field that could ever be exposed.

That philosophy influences nearly every design decision inside CriticalBuzzer.


Our Security Principles

Every decision we make is guided by five principles:

  1. Collect the minimum data necessary.
  2. You control what gets sent.
  3. Protect data in transit and at rest.
  4. Be transparent about how data is used.
  5. Earn your trust every day---not just when you sign up.

Final Thoughts

CriticalBuzzer exists to tell you when something important changes, not to become another repository for your customer data.

Our goal is simple:

**Help you detect problems earlier while encouraging the smallest possible data footprint.**

That's good for security.

That's good for privacy.

And ultimately, it's good for your customers.