Alerting

Capturing errors only helps if the right people hear about them. Quiet Guard sends alerts through per-project notification channels when meaningful events happen.

Notification channels

Each channel belongs to a project and is managed from the project's Alerts tab in the /app panel. A channel has a type, a target, and a set of subscribed events. Three channel types are supported:

TypeTargetNotes
Mailan email addressSends a notification email.
Slacka Slack incoming webhook URLPosts to a Slack channel.
Webhookan HTTPS endpointPosts a JSON payload to your own service.
Slack and webhook channels are part of the paid plans, Indie and Studio. On Free the form refuses those two types, and mail carries the alerts. A channel created on a paid plan is never deleted when a team moves back to Free: it is kept as you configured it, wears a badge in the table and stops firing until the plan carries it again. Mail alerts are on every plan, Free included.

A channel can be enabled or disabled, and only fires for the events it is subscribed to.

Subscribed events

When you create a channel you choose which events it should react to:

  • issue.created: a brand-new issue was seen for the first time.
  • issue.reopened: a resolved issue happened again (a regression).
  • vulnerability.detected: a new dependency vulnerability was found for the project (see Dependency security).
  • heartbeat.overdue: a scheduled task stopped pinging (see Heartbeats).
  • uptime.down and uptime.recovered: the probed URL stopped answering, and answered again (see Uptime monitoring).
  • ssl_expiring: the TLS certificate of the probed URL is approaching its expiry date.

A channel only notifies when it is enabled and subscribed to the triggering event. Issue alerts are dispatched after the occurrence is persisted; vulnerability alerts are dispatched when a dependency scan finds new findings.

SSRF-guarded webhooks

Webhook and Slack targets are URLs that the server will call. To prevent server-side request forgery, every outbound webhook is validated before it is sent:

  • URLs are checked by a public-URL rule when you save the channel: private, loopback and internal addresses are rejected.
  • The dispatcher resolves the host and refuses to call internal/reserved network ranges.
  • HTTP redirects are disabled, so a public URL cannot redirect the request to an internal one.
Why this matters: without these guards, an attacker who could set a webhook target might point it at http://169.254.169.254/ or an internal service. Quiet Guard blocks that class of attack at save time and at send time.

What an alert contains

An alert identifies the project, the event, and the issue or findings involved, with a link back to the dashboard.

Encrypted teams: if encrypted storage is active, alerts are generated server-side with no access to your passphrase, so they can only include metadata and a dashboard link, never the sealed message or stack trace. This is by design: zero-knowledge at rest means the alerting path cannot read your content either.

Scheduled-task heartbeats

Exceptions tell you when code fails loudly; heartbeats catch the tasks that fail silently, a lost cron entry, a misconfigured scheduler, a job disabled and forgotten. Each scheduled task pings Quiet Guard after it runs; when the pings stop, the channels subscribed to heartbeat.overdue are alerted once per outage. The concept, setup and tuning have their own page.

Uptime and certificate alerts

The active uptime probe fires uptime.down / uptime.recovered on transitions (one alert per outage, one per recovery), and the daily certificate watch fires ssl_expiring at 14 then 3 days to expiry. Probing, latency history and the public status page are covered on the uptime monitoring page.

Alert-storm protection

A broken deploy can spawn dozens of distinct issues in minutes. Each notification channel has a rolling alert budget (10 alerts per 10 minutes by default, operator-adjustable; 0 disables the limit): past the budget, further alerts are suppressed and the channel receives one "alerts paused" notice with a link to the dashboard. Nothing is lost, every issue keeps being recorded and stays visible.

Weekly digest

Every Monday morning, each team owner receives a weekly digest by email: new issues, event volume, the three noisiest issues with their occurrence counts, open vulnerabilities, overdue heartbeats, month usage with its end-of-month projection, and backup storage. The lines carry no deep link, only a single button back to your dashboard. Quiet weeks are skipped, no empty emails. The operator can disable the digest globally.

You are reading the Quiet Guard v1.0 documentation.