Skip to main content
A finding that only exists on a screen you have to open is a finding you read when you were already worried. Connect a channel to a source and its findings arrive there instead — with nobody here in the loop, and whether or not anybody opens this product that week. This page is about the outbound half: what leaves, what stops it leaving, and how you tell the difference between a quiet week and a broken one.

​
Connect a channel

A destination is one URL that accepts a POST with a JSON body. Slack, Microsoft Teams and Discord all issue one; so does anything you write yourself. We do not ask you to install an app, and we never pick your chat vendor for you.
The URL must be https. The label is what the Sources screen prints, because a webhook URL is a secret and a screen that renders one has leaked it — we store the URL, show you the label, and never read the URL back out through any route.
Connecting a channel does not backfill. Findings raised before the destination existed stay on the Findings screen and are not replayed into it. A channel that filled up with three months of history on the day it was connected would train the team receiving it to mute the channel, which is the one outcome this feature cannot survive.

​
What arrives

One message per finding, in the same words the Findings screen uses. It carries the claim, the evidence behind it, and — when we can say it — the build it followed. It never carries anything we cannot check. It arrives with nobody in the request. The rule that raises a finding runs on its own schedule — about every five minutes — and delivery runs on a second schedule behind it, about every ten minutes. Nothing here waits for a person to press anything, and no message is ever composed by hand. Nothing in it can page you. A message from this product cannot mention a channel, a group or everyone, and cannot raise an incident on your side. That is not a setting — there is no field for it, and a message that somehow contained a broadcast mention is refused before it leaves rather than posted quietly. If something here should wake a person up, a person decides that, from the finding.

​
The daily ceiling

Each destination has a daily ceiling: the most messages that may be sent to it in one UTC day. It defaults to 20. A message counts against the ceiling once it has been sent, whatever your endpoint does with it. A rejected message was still sent, and a ceiling that counted only the successful ones would be no ceiling at all on the day your endpoint answers 500 to everything — which is exactly when it matters. The ceiling is a limit on the size of a mistake, not a way of avoiding one. It exists because the failure it guards against is unrecoverable in a way the others are not: a rule that misfires into your channel four hundred times is a channel you mute, and a muted channel cannot be un-muted by us fixing the rule. When the ceiling fires, the source stops reading as healthy. It shows Ceiling reached on the Sources screen, with the number withheld and the ceiling that withheld them named as the reason. That is deliberate, and it is the whole point of having the state:
  • The findings are not dropped. Each one is recorded as withheld, with the ceiling named, and every one of them is still on the Findings screen.
  • A ceiling firing and a week with nothing to find must never look the same from your channel — and from your channel they look identical, because both are silence. So the difference is made visible where you can see it.
Raise the ceiling by connecting the destination again with a larger dailyCeiling. The count resets at midnight UTC.

​
When a destination fails

If your endpoint rejects a message, or does not answer within ten seconds, the failure is written down against the source and shown on the Sources screen — the status code or the timeout, and when it happened. The source reads Delivery failing rather than healthy. It is on the screen rather than in a log because nobody reads logs for an absence. The failure mode this is aimed at is a channel that was archived, or a webhook that was revoked, six weeks ago: everything on your side looks fine, and the only evidence is messages that never came. Failed messages are not retried into a backlog. The finding stays on the Findings screen and the next finding is attempted normally, so a destination that comes back does not first replay everything it missed.

​
One line a week

Once a week each destination gets a single line about the sources feeding it. It is not a digest of findings — it is the two facts that separate a genuinely quiet week from the failures that look exactly like one:
  • The age of the last stored signal, per source and per kind. Errors and deploys are aged separately and never averaged. A source storing errors every minute while it has stopped storing deploys reads as fine under one number, and deploys are what a finding needs in order to name a build.
  • The proportion of your errors that could not be judged — the share that named no release we could match to a deploy we hold. A finding from one of those cannot say which build it followed.
Both figures are the same numbers the Sources screen shows you, from one definition rather than two that happen to agree. If one moves, the other moves with it. The line goes out once every seven days per destination. A week that is missed is not sent late alongside the next one.

​
Nothing arrives while a source is establishing

A newly connected source is deliberately quiet for its first fortnight, and that quiet covers your channel as well as the Findings screen. During it:
  • Findings are still made and still recorded. The quiet stops them reaching you, never stops them being made.
  • Nothing at all is posted to your channel — not the findings, and not the weekly line.
  • The Sources screen names the date after which findings can arrive, not just the word “waiting”. A suppression window you cannot see the end of is indistinguishable from an integration that never worked.
That date is the same one printed on the source’s row and in the message you hand the team who owns it. It is fixed when the source is connected and it does not move.

​
Before you call a week quiet

The rule that produces findings runs on a schedule. A rule that has stopped running and a week with nothing to find produce the same thing in your channel: nothing. So the product checks its own schedule first. If the rule has not run inside its expected interval, the Sources screen says so — the week’s headline reads “The rule that finds things has not run”, with when it last did — and it refuses to describe the week as quiet until that is resolved. A quiet week is a claim, and it is only made on evidence that covers it. The three silences you may be looking at, and how to tell them apart:

​
Disconnect a channel

Nothing further is posted, and the record of what was delivered to that destination goes with it. Findings themselves are untouched — they stay on the Findings screen, and connecting a new destination starts a fresh record rather than replaying them.