Skip to main content
Monitored repos scan themselves on every push — notifications close the loop by telling you when one of those scans found something new, so nobody has to keep a dashboard open.

​
What triggers a notification

All three conditions must hold:
  1. The scan was automatic (push-triggered on a monitored repo). Manual scans never notify — you’re already looking at the result.
  2. The scan surfaced at least one new finding, per cross-scan diffing. Re-detections of known findings stay quiet, so a busy repo doesn’t spam the channel on every push.
  3. Notifications are configured and enabled in Settings.
The message names the repo and branch, counts the new findings, summarizes the current open-findings posture, and links to the repository page in Pipefort.

​
Setup

  1. In Slack, create an incoming webhook for the channel that should receive alerts (see Slack’s guide).
  2. In Pipefort, open Settings → Integrations, click Connect on the Slack row, paste the webhook URL, and Save.
  3. Click Send test — a confirmation message should appear in the channel.
Use the toggle to pause notifications without deleting the webhook, or Remove to delete the configuration entirely.
Only https://hooks.slack.com/… URLs are accepted. Pipefort’s server delivers these messages itself, so it restricts destinations to Slack rather than posting to arbitrary user-supplied URLs. Slack-compatible endpoints (e.g. Mattermost) are a planned follow-up.

​
Semantics worth knowing

  • Notifications are per user: when a monitored repo’s automatic scan finds new issues, every member of that organization with notifications configured gets the message on their own webhook — each member’s settings decide whether (and where) they’re notified.
  • Delivery is best-effort: a Slack outage never fails or delays the scan itself. Failed deliveries are logged server-side and not retried.
  • The webhook URL is stored for your account and treated as a secret — it is never included in server logs.

​
The Alerts page

Alerts in the console rail is the feed of what changed, over the last 30 days, newest first and grouped by day. Each row is a change, not a finding. A scan that turns up four HIGH problems is one interruption, so its events are rolled into one row per scan, per repository, per severity; a fix pull request that covers three findings is one row. Triage decisions stay individual, because each one is somebody’s judgement about a specific finding. The feed reads finding_events, the append-only transition log, plus the scans table for failures — a scan that errored never produced findings, so the log has nothing to say about it, and a repository that quietly stopped being scanned is exactly what a posture screen will not tell you about.
Three kinds of alert in the design cannot appear, and the page says so at the bottom rather than leaving you to notice. New toxic combinations are computed on read and never stored; SLSA levels are derived per scan and never compared with the previous one; rule settings record what is muted now, not when it was muted. None of them can be dated, so each is listed with a link to the screen holding today’s answer.

​
Unread

Unread / all filter the feed, and Mark all read clears the count. The rail badge beside Alerts is the same unread tally, and disappears at zero. Read state is a watermark: one timestamp per person per organization, and unread means “happened after it”. You cannot read the middle of the list and leave the rest unread — which is the trade almost every feed of this shape makes, and the right one for a count whose whole job is to say something happened since you last looked. Watermarks are per person. Marking the feed read does not mark it read for your colleagues, and a feed you have never opened counts as entirely unread rather than entirely seen. For the same reason there is no per-event subscription — you cannot choose to be told about HIGH findings but not MEDIUM ones. Slack delivery is all-or-nothing, on the three conditions above.

​
Mutes

The Muted panel counts every rule turned off in Rule policy, whether org-wide or for a single repository, and names the repository for the repo-scoped ones. Mutes do not expire. Nothing stores an expiry date for a rule mute, so a rule stays off until someone turns it back on — worth knowing before muting a rule to get through a release.