> ## 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. # Reading a quiet week > A week with no findings can mean nothing went wrong, or that a source stopped talking to us. The sources screen tells you which of those it can prove, and says plainly where it cannot tell. Few findings, each of which mattered, is the outcome this product is for. So "nothing was found this week" has to be a reading you can trust — and on its own it is not one, because several different situations produce exactly the same empty screen. The **Sources** screen answers that question, and this page is what it means. ## The week, in one line At the top of Sources you will find one sentence about the window behind you — seven days — and it says one of three things. | It says | It means | | --------------------------- | ------------------------------------------------------------------------- | | **The week was quiet.** | Every source stored something inside its own limit, and nothing was found | | **Nothing was found, and…** | Nothing was found, and at least one source cannot be read as healthy | | **… findings this week** | Findings were raised. The week was not quiet, and the count says how many | The middle row is the one worth knowing about. A week with no findings and a source that has gone quiet is **not** a quiet week — it is a week the product cannot vouch for, and the line says how many sources it cannot vouch for it on. Which ones, and why, is on their own rows below — see the next section. ## Zero findings is never shown on its own Under that line, every source shows the age of its **last stored signal, per kind** — errors and deploys separately, in every state, including the healthy ones. That is deliberate and it is the whole point of the screen. A source that looks healthy over a three-day-old age is exactly what a silently paused integration looks like, and hiding the age in the good state is how one goes unnoticed for a whole week. So the ages are always on screen, next to the verdict, and you can compare them to your own clock. The limits after which a source stops describing itself as storing: | Kind | After | Because | | ----------- | -------- | -------------------------------------------------------------- | | **Errors** | 24 hours | A short limit, because the failure it catches is itself silent | | **Deploys** | 72 hours | A small team legitimately ships nothing over a weekend | Neither has been measured against real traffic. They are printed on the screen so that the day one of them is wrong, you can see it rather than take it on trust. ## What a silence proves depends on who sent it The two vendors are not the same, and the screen does not average them. ### GitHub — a silence is evidence A repository webhook fires on every push, every deployment and every deployment status, unthrottled. A repository that has said nothing for longer than its limit has **stopped**, and the screen says so, names the kind, and states the age. ### Sentry — a silence is not evidence On the route we recommend and document, Sentry reports an issue the first time it appears and at most once every 30 minutes per issue afterwards. It reports nothing at all when nothing is firing. How quiet a perfectly healthy Sentry source is therefore depends on a rule inside your Sentry account, and on whether anything is going wrong. So a Sentry source past its limit is shown as **quiet** — neither health nor an alarm. Its age is stated, it is never marked as a fault, and no sentence on it suggests anyone did anything wrong. Every quiet Sentry source carries the same sentence, not just the ones that look suspicious: an alert rule still in place on a product with nothing going wrong, and an integration deleted at Sentry, produce identical evidence here — nothing at all — and the product cannot tell which one it is looking at. ## Two things a quiet reading might really be The screen says both of these on itself, where the reading is, rather than leaving them here. **A rotated secret looks exactly like quiet.** Deliveries are verified against the secret on the source. If your Sentry Client Secret is regenerated, or a GitHub webhook secret is changed on your side, the next delivery is refused — and until something actually fires, there is no next delivery. Between the rotation and the next event, a rotated source and a genuinely quiet one are identical from here, and the product cannot tell them apart. When a delivery does arrive and is refused, the source moves to **Arriving but refused**, which says so on the row and tells you which secret to replace. **Delivering and storing nothing is a different problem.** A source that is receiving deliveries while storing none of them shows as **Delivering, storing nothing** — a distinct state, with distinct words, listing the delivery types that arrived beside the ones we read. It is not a silence: every delivery-level indicator is green and no evidence is being collected at all, which is why it is the loudest state on the screen. Receiving nothing and receiving-but-storing-nothing are never shown the same way. One is a disconnection, the other a misconfiguration, and they send you to two different places. ## The one quality figure Beside the verdict is the share of the errors stored this week that carry **no usable release**. A release is usable when the error names one and a deploy we have stored matches it. Errors without one still produce findings — weaker ones, that cannot say which build they followed. It is a proportion rather than a count on purpose: it is a quality figure, not an outage. And it is a question asked of the stored deliveries each time it is read, not a verdict stamped on the row when it arrived. That has two consequences worth knowing: * **The number can be corrected backwards.** We keep the raw body of every delivery, verbatim. When we get better at reading a release out of it, the figure for weeks already behind you improves too. * **A deploy that arrives late still counts.** The matching deploy sometimes reaches us seconds after the error it explains. Because the match is made at read time, the error stops being unattributable the moment the deploy lands. The same figure, from the same definition, is what appears in the weekly line sent to your team. There is one calculation behind both, so they cannot disagree. ## What this screen still cannot tell you It reads what your sources can answer, and no more: * Whether a rule inside our product has run at all * Whether a daily ceiling on findings was reached * Whether a source is still inside its establishing window Those are facts other parts of the product produce, and they are shown where those facts exist. Until all of them are, a quiet week here means *quiet as far as the sources can say* — which is why the ages are always beside the verdict.