What does it cost you that a hosted scheduled run's definition lives in a vendor account rather than your repository?
answer
- Production configuration with no history
- No diff, no blame, no revert
- Two copies drift; one is authoritative
- It degrades toward green, not red
- Absence of runs must itself be an event
basics
~20 sThe schedule and the copy it runs are production configuration with no version control: no diff, no review, no blame, no revert. Anyone with account access can change or pause it, and a paused schedule looks like a passing one.
solid answer
~50 sEverything that decides what runs, how often, and against which environment is recorded in somebody's account, so the ordinary safety net is missing: there is **no commit, no diff, no review, no blame and no revert**. Three failure modes follow. The hosted copy of the collection drifts from the repository copy, so a green result may be green about requests you no longer make. The scope can be narrowed — a smaller folder, a different environment — and the result still reads green. And the schedule can be paused or its account can lapse, at which point it emits nothing, which is indistinguishable from health. The mitigation is arrangement, not tooling: keep the repository copy authoritative, publish the hosted copy from it rather than editing in place, write down who may change the schedule, and treat an absent run as an event.
go deeper
Remember that the schedule and the copy it runs are not in your repository, so there is no commit history behind them. A change there leaves no diff for you to read later.
Explain the three ways it degrades toward green — a drifted copy, a narrowed scope, and a paused schedule — and why each is harder to spot than an outright failure.
Show the habits: one authoritative copy in the repository, the hosted copy republished from it, ownership and edit rights written down, and something outside the account that notices runs have stopped arriving.
Own the governance question: how much unreviewed operational configuration your organisation is willing to hold in vendor accounts, who audits it, and how a newcomer discovers it exists at all.
## Configuration with consequences and no history The collection is a file, and files live in version control where changes are proposed, reviewed, attributed and reverted. A **hosted scheduled run** is not a file you hold. What runs, on what cadence, against which environment, with which stored credentials, and who is notified — all of that is recorded inside a vendor account. It behaves like production configuration and it has none of production configuration's discipline. Spell out precisely what is missing, because that list is the answer: - **No diff.** You cannot see what the schedule looked like last month. - **No blame.** You cannot see who changed it, unless the vendor's own record happens to say so and somebody thinks to look. - **No review.** A change takes effect because one person with access made it, not because a second person agreed. - **No revert.** Undoing means remembering the previous state and re-entering it. - **No branch.** There is no way to try a change in isolation; the edit is live. An interviewer is testing whether you notice that a whole class of change in your system escapes your change-management process entirely. ## Three ways this bites | Failure mode | What you observe | Why it is deceptive | |---|---|---| | **Copy drift** | continuous green | the hosted copy is an older collection, asserting things you stopped doing | | **Silent narrowing** | continuous green | the run now covers a smaller slice, or points at an environment that is easy to satisfy | | **Quiet stop** | nothing at all | a paused schedule or a lapsed account emits no failures, and no failures is what success looks like | All three share a property that makes them worse than a plain outage: **they degrade toward green.** A broken pipeline goes red and shouts. A neglected hosted schedule goes quiet and reassuring. The strongest single sentence you can offer here is that in this arrangement, *the absence of a signal is not evidence of health*, and something has to treat a missing run as an event. ## Who may change it Access to the account is the real permission model. That has two edges: 1. **It is broader than your repository's.** People who cannot merge to your default branch may still be able to edit what a scheduled run does and when, because account membership and repository access are governed separately. 2. **It is invisible from your side.** Nothing in your repository records that the schedule exists, let alone who may touch it. A newcomer reading the codebase has no way to learn that a check is running against production every day from outside. So part of the cost is **discoverability**: a component of your operational feedback loop is undocumented in the place engineers actually look. ## Making the arrangement survivable The fix is not a feature; it is a set of habits that put the repository back in charge. 1. **Declare one source of truth.** The collection in your repository is authoritative. The hosted copy is *derived*, and it is republished from the repository rather than edited in place. As soon as somebody edits the hosted copy directly, you have two suites and no way to reconcile them. 2. **Write the schedule down where the code is.** Even a short note in the repository — what is scheduled, roughly how often, which environment it targets, who owns it, who may change it — restores discoverability that the vendor's account cannot give your codebase. 3. **Verify the hosted copy periodically.** Re-publish on a rhythm, or compare, so drift has a bounded lifetime. Trust decays with time since the last sync. 4. **Treat pause as a change that needs a reason.** Pausing is the easiest way to make a noisy check stop, and it is silent. Whoever pauses one should record why and when it comes back. 5. **Detect absence, not just failure.** Something outside the vendor's account should notice that runs have stopped arriving. Whether that is a dashboard, an alert or a human check is an observability design question; that it must exist is this arrangement's problem. 6. **Keep the hosted set small.** The more of your suite runs on somebody else's clock, the more unreviewed definition you are carrying. ## The sentence to say out loud "The schedule is production configuration that my version control never sees, so I keep the repository copy authoritative and publish the hosted one from it, I write down who may change it, and I make sure something notices when it goes quiet — because in this arrangement, quiet and healthy look identical." That answer shows you understand the cost rather than reciting that the tool is convenient.
- Which copy of the collection should be authoritative, and why does the direction matter?The repository copy. It is the one with history, review and revert, and it is the one engineers find. Making the hosted copy authoritative means every edit to your test suite happens in a place with no diff and no reviewer, and your repository trails behind whatever somebody typed into an account last week.
- How would you notice that a hosted schedule has been quietly narrowed to a smaller scope?By comparing what is scheduled against the authoritative copy rather than by watching the result, because a narrowed run still reports green. Republishing the hosted copy from the repository on a rhythm bounds how long a narrowing can survive, and a written record of what is supposed to be scheduled gives you something to compare against.
It is a spare key held at a neighbour's house: useful, but nothing in your own records says it exists, who has borrowed it, or whether it still turns the lock.
saying these in an interview costs you the question
- Assumes a change to the schedule leaves an auditable trail you control
- Treats a long green streak as proof the check still runs
- Lets the hosted copy become the real source of truth
- Believes repository access governs who may edit the schedule
- Never records anywhere in the repository that the schedule exists
- Pauses a noisy schedule without recording why or when it returns