A new field-service scheduling version reaches a small group. There are no errors and response times look healthy, so the team expands the release. Later it discovers that the new assignment logic ignores a working-hours restriction. Nobody in the initial group happened to use that kind of schedule.
Canary Deployment evaluates a change on a limited part of real production work before full rollout. A small audience alone does not establish safety. The team needs to know what the candidate actually processed, what it was compared with and which failures it could detect in time.
Choose a participation unit, not just a percentage
Routing a fraction of requests is convenient. For a user, it may mean one page runs on the candidate and the next on the stable version. If they interpret sessions or intermediate state differently, switching between them creates an additional scenario neither version encounters alone.
For field-service scheduling, a branch or operating team might be a more useful unit. Related changes to a shared schedule then stay together. But a small branch with only simple schedules does not represent the whole company. The initial group should both contain risk and include relevant cases.
The percentage of application instances is not an exact percentage of requests. Long connections, client behaviour and balancing affect distribution. Without dedicated traffic management, Argo Rollouts, for example, approximates weights using replica counts. Evaluate actual requests and business operations reaching the candidate.
Compare versions at the same time
Comparing the morning after release with the previous night is easier than maintaining a control group. Traffic and job complexity may have changed independently of the code, however. Canary evaluation is more useful when candidate and stable populations operate under comparable conditions and remain separately observable.
An aggregate product dashboard can hide serious failures in a small group. Associate errors, latency and business outcomes with the version and rollout stage. Even then, compare like with like: if the candidate receives the hardest appointments, a different success rate is not automatically a regression.
For a dispatcher, HTTP success does not establish a correct assignment. The technician must be available, the schedule must remain consistent and the appointment must complete the required workflow. The Google SRE Workbook discusses population and metric selection. It does not provide one universally safe traffic percentage.
No observed error is not the same as a completed check
A handful of successful requests may never exercise the changed function. A background job may run only on a schedule; a mistaken assignment may become apparent only after the technician responds. Observation needs to cover the relevant work, not merely the uptime of the new process.
Define advancement conditions in advance: what must complete, what stops the release and what happens when evidence is missing. If telemetry collection fails, the absence of a red chart should not automatically expand exposure. Pausing is a legitimate outcome rather than a delivery malfunction.
Some tools represent uncertainty explicitly. Argo Rollouts analysis supports an inconclusive outcome that can pause progression for human judgement. Check the behaviour of the actual rules: a failed metrics query, an empty result and healthy observations must not accidentally receive the same interpretation.
Waiting indefinitely is not the answer either. If the necessary cases rarely occur in the selected group, change the evaluation: use controlled scenarios or another authorised cohort. Watching unsuitable traffic for longer does not make the conclusion stronger.
A shared database can spread harm beyond the cohort
The candidate may write a state the stable version cannot read or exhaust a shared resource with an expensive query. The control population then suffers too. Canary routing limits directed work; it does not automatically isolate data or capacity.
Before release, check record formats, messages and shared settings. A destructive migration of the whole database is not made safe by exposing the new interface to a few users. Such changes require their own transition sequence, with related limitations discussed under Blue-Green Deployment.
By the time rollout stops, the candidate may already have assigned a visit and sent a notification. Routing back does not cancel either action. The team needs to identify affected operations and repair them. The stable deployment also needs capacity for returning traffic and retries from failed attempts.
Release safety is not the same as product effectiveness
A canary primarily helps decide whether to expand a change under defined criteria. A feature experiment may ask a different question: does the new behaviour improve the product? That conclusion requires appropriate groups and evaluation; one quiet release stage cannot establish it.
A feature flag can control behaviour separately, but does not replace deployment checks. A disabled feature may remain inactive while an updated library already affects every request. Distinguish code delivery, feature activation and shared-data changes so their effects can be understood.
Expansion creates a new test condition
A larger population brings different data and more load. A successful small stage does not prove that shared dependencies can handle the full request rate. Evaluation continues during expansion rather than ending after the first approval.
A short release record can capture the version, actual cohort, exercised scenarios, observed effects and decision owner. Record what remains untested. Concurrent changes can contaminate signals; separate them or account for their interaction explicitly.
For the scheduling system, proceed after evaluating the relevant working-hour patterns and completed assignments. Then saying the initial stage passed describes work that actually succeeded, not simply a period when nobody called support.