> ## Documentation Index
> Fetch the complete documentation index at: https://docs.scaling.cloud/llms.txt
> Use this file to discover all available pages before exploring further.

# Findings in your own channel

> Connect a channel to a source and its findings arrive there unasked for, with a daily ceiling you can see and one line a week about what the source could and could not tell you.

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.

```bash theme={null}
curl -X POST https://api.scaling.cloud/sources/src_.../destination \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
        "endpoint": "https://hooks.example.com/services/T000/B000/xxxx",
        "label": "#payments-alerts",
        "dailyCeiling": 20
      }'
```

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.

<Note>
  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.
</Note>

## 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](/guides/how-an-investigation-opens) — 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](/guides/your-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:

| What you see in your channel | What the Sources screen says                                       | What it means                                                  |
| ---------------------------- | ------------------------------------------------------------------ | -------------------------------------------------------------- |
| Nothing                      | "The rule that finds things has not run"                           | We are not looking. Nothing about your week is known yet       |
| Nothing                      | `Ceiling reached`                                                  | Findings exist and were withheld. The opposite of quiet        |
| Nothing                      | `Established, waiting`, with the date findings can start beside it | We are looking and holding. Findings can arrive from that date |
| Nothing                      | `Delivery failing`                                                 | Findings exist and your endpoint refused them                  |
| Nothing                      | Every source healthy                                               | A quiet week, and we can say so                                |

## Disconnect a channel

```bash theme={null}
curl -X DELETE https://api.scaling.cloud/sources/src_.../destination \
  -H "Authorization: Bearer $TOKEN"
```

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.