> ## 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. # Leaving the sources screen open > The sources screen keeps itself up to date without being reloaded, and says so plainly when it cannot. The sources screen is meant to be left up. Its whole subject is a source going quiet, and a screen you have to remember to reload is a screen that tells you about a silence only once you already suspected one. So it checks in with us on its own. ## What happens while it is open Every **30 seconds** the screen asks for the whole page again — every source, what each one is storing, the per-kind ages, and the week's line above them — and redraws from the answer. You do not reload, and you do not click anything. The ages advance on each check-in. A source that read "last stored 4 minutes ago" reads five, then six, and the moment a delivery lands it drops back to seconds. That is the signal you left the tab open for. The screen keeps doing this for as long as it is open. There is no cut-off after which it quietly stops and shows you a page that is an hour old. The ages are worked out in your browser from the instants we sent and the clock we stamped on the answer, so the number in front of you keeps moving between check-ins rather than freezing until the next one. ## When we cannot answer A check-in either brings back the whole page or it brings back a failure. There is no half-drawn state: you will not see the sources without the week's line, or the week's line with the ages missing, because one half of the answer arrived and the other did not. If any part of it fails, the whole check-in fails: the screen replaces the page with a plain statement that it could not ask, and a button to ask again. It does not leave the last ages up as though they were still being checked. That matters more than it sounds. A screen that silently dropped half its answer would show a quiet source as quiet for a reason that was never checked, and you would have no way to tell that from the real thing. ## What it costs you One request per check-in, and it is gathered rather than asked in sequence. A refresh therefore costs you far less than every part of the answer added together, and connecting a fifth source costs you the fifth source rather than another full wait on top of the four. It asks for a **bounded** number of things at once, and the bound does not move with how many sources you have connected. A check-in with a hundred sources holds no more of us at one time than a check-in with three; it simply works through more of them. That is why a very wide account's refresh does not scale straight down with its source count — and it is the same bound that keeps the screen cheap to leave open, for you and for everybody else leaving one open at the same time. ## What it never costs you **Leaving this screen open cannot delay a delivery.** The capacity that accepts signals from your monitoring tool is held apart from the capacity that draws screens, and nothing drawn on a screen — this one or any other — is allowed to take it. Every tab your team leaves up, and every tab every other team leaves up, is competing for the screen half and not for the half your errors arrive through. That ordering is deliberate, and it runs the way round you would want it to. If enough screens are open at once that something has to wait, the thing that waits is the screen. A check-in may come back a little later than usual; a delivery from Sentry or GitHub is accepted in the time it always takes. If a check-in ever does wait, you will not see a half-drawn page or a stale one — the behaviour above still holds. It arrives late, whole, or it fails and says so.