What is a hosted scheduled run of a Postman collection, and how does it differ from running that collection yourself?
answer
- Same file, different driver
- A clock nobody on your team holds
- Enters from outside your network
- Verdict recorded in their account
- Definition never reaches your version control
basics
~20 sA hosted scheduled run executes the same Postman collection on the vendor's machines, on a clock kept in their account rather than yours, from outside your network, and records the verdict there instead of in your build.
solid answer
~50 sThe collection does not change; **who drives it does**. In your own run you trigger the collection from a machine you control, inside your network, with credentials from your own store, and the result lands in your own output. On a hosted schedule the vendor holds a copy of that collection in their account, starts it on a clock nobody on your team touches, runs it from their machines over the public internet, and records the verdict on their side. Three consequences follow: the definition of what runs and when sits outside your version control; the run exercises the path a stranger takes into your system; and the failure notice arrives with no commit, no author and no build attached. Driving the same collection from a terminal, and what a build step does with a result, are separate subjects.
go deeper
Be ready to say plainly that the collection is the same document, but somebody else's clock starts it, on their machines, and the result is kept in their account rather than in your build output.
Explain the four substitutions — trigger, machine, identity, record — and what each one implies. Name at least one thing this arrangement can see that an in-network run cannot, and one thing it costs.
Show that you treat the hosted copy as derived from the repository copy, that you know who is allowed to edit the schedule, and that you watch for a schedule going quiet as carefully as for one going red.
Own the placement decision: which checks are worth putting on somebody else's clock at all, how small that set stays, and what your feedback loop does when that vendor's platform or that account becomes unavailable.
## The arrangement, not an interface A Postman **collection** is a portable document: requests, the scripts attached to them, and the folders that order them. A **hosted scheduled run** takes that same document and puts it somewhere else to be executed — the vendor's platform holds a copy in an account, starts it on a clock kept there, and executes it on their machines. Nothing about the collection itself is special. The interview question is never *what syntax describes the schedule*; it is **what changes when the thing that drives your collection is a clock you do not hold, on machines you do not own, reporting to a place that is not your build**. That is why this topic is about an arrangement rather than an API. Everything interesting follows from four substitutions, and a candidate who can name them has answered the question. ## What moves and what stays put | Piece of the run | Your own run | Hosted scheduled run | |---|---|---| | The collection | a copy your repository holds | a separate copy held in the vendor's account | | The trigger | a person, or an event in your own pipeline | a clock nobody on your team holds | | The machine | an agent or laptop you control, inside your network | their machines, reaching you from outside | | The identity | credentials from your own store | credentials stored in that account | | The verdict | your run's own output | a record kept on their side | | First to know | whoever caused the run | whoever holds the account | Read the table as a single sentence: **the artefact stays, the operator changes.** Every difficulty in this area is a consequence of that one swap. ## What the swap buys you - **Execution with no change behind it.** Your own runs happen because somebody pushed or somebody clicked. A hosted schedule keeps running through the long quiet between deploys, so a failure caused by something other than your code — an expired certificate, a dependency you call, a configuration edited by hand — still surfaces. - **An origin outside your network.** The request enters the way a customer's would: through public name resolution, your edge, and whatever sits in front of the service. A run started inside your own network structurally cannot exercise that path. - **Independence from your pipeline's health.** If your build system is down, the schedule still runs. That cuts both ways, as the next section shows. ## What the swap costs you - **A second definition outside review.** What runs, how often, and against which environment is recorded in the vendor's account. There is no commit for it, no diff, no blame, and no revert. - **A live credential you do not hold.** Whatever the run needs to authenticate is stored in that account, and rotating it on your side does not rotate it there. - **A verdict detached from a change.** The notice says a request failed at a time. It does not say who pushed what, because usually nobody pushed anything. - **Silence that looks like health.** A schedule that is paused, or whose account lapses, produces no failures at all — and no failures is exactly what success looks like. - **A dependency on somebody else's availability.** Their clock is now part of your feedback loop. ## What this is not Several neighbouring subjects are commonly confused with this one, and an interviewer will notice if you wander into them: 1. **It is not a build step.** Running a collection from a terminal, and the exit status a build step reads from it, belong to the command-line runner and to pipeline design. 2. **It is not alerting.** How a failure is routed, deduplicated, or displayed on a dashboard is an observability subject in its own right. 3. **It is not a measurement theory.** Whether a scheduled check is a good indicator of service health, and what it misses compared with real traffic, is a service-level question owned elsewhere. The part that belongs here is narrower and more concrete: **where the definition lives, who may change it, whose clock starts it, and where the answer is written down.** ## Answering it well Open with the substitution — same collection, different driver, different origin, different record. Then give one benefit and one cost in the same breath: it runs when nobody pushed and from outside your network, and in exchange you now maintain a copy of your suite that your version control never sees, guarded by an account rather than a review. Finish by saying what you would do about it: keep the repository copy authoritative, publish the hosted copy from it, write down who may edit the schedule, and remember that a quiet schedule is not the same as a passing one.
- If the collection is identical, why would a hosted scheduled run ever disagree with your own run of it?Because everything around the collection differs. The hosted run starts from outside your network, carries credentials stored in that account, targets whatever environment the hosted copy points at, and may be running an older copy of the document. Disagreement is usually about origin, identity, or copy drift rather than about the requests themselves.
- Where does the result of a hosted scheduled run live, and why does that matter?It is recorded on the vendor's side, in the account that owns the schedule. That matters because your build history has no trace of it: nothing failed in your pipeline, no commit is marked, and getting the verdict in front of the right engineer is an arrangement you have to make deliberately rather than something the run gives you.
It is the difference between trying your own front door from inside the house and paying a neighbour to rattle the handle every morning while you are away.
saying these in an interview costs you the question
- Calls it a build job that merely happens to run elsewhere
- Assumes the schedule runs whatever the repository currently holds
- Expects the verdict to appear in the build output
- Believes the run originates inside your own network
- Thinks the schedule's definition is under version control
- Treats a long run of green results as proof it is still running