What percentage of traffic should a canary release start with? How long without anomalies should you wait before switching to full?

There is no fixed percentage or time formula for switching from canary to full rollout. Based on typical delivery experience in 2026, start with a small traffic of 5%–10%, observe for 30 minutes to 2 hours with no anomalies, then ramp up in steps of 10% → 20% → 50% → 100%. Most of the process completes within 0.5 to 2 working days. What truly supports the decision to switch to full rollout is that signals such as API error rate, timeout rate, and business success rate remain consistent with the pre-canary baseline, not that you have already waited 24 hours.

Why isn't half an hour without errors enough reason to switch to full?

A zero API error rate does not mean the business is fine. Common counterexamples: the API returns 200 but the checkout page does not redirect; P95 is normal but one channel shows a white screen; the database connection pool reaches a critical point but has not exploded yet. Therefore, the observation window should not only cover key business periods, but also examine the outcome metrics of the business flow.

Before the formal release, pull up the monitoring baseline: API error rate, P95 latency, requests per minute, and core business success rate. If metrics are missing, use log sampling or SQL reconciliation as a substitute. Do not wait until problems occur to fill the gap.

For read-heavy query services, 30–60 minutes during off-peak hours is sufficient. For order, payment, or fund-flow related services, at least one business peak must be covered, with observation for 2–4 hours or one reconciliation cycle.

Experience ranges for traffic ramp-up in different business scenarios

The following are not golden ratios, but typical experience ranges observed in 2026 projects. You can use them as a starting reference.

• Internal management systems or off-peak releases: 5% → 30% → 100%, with 15–30 minutes per step; suitable for small user bases and low rollback cost.
• Typical web/app services: 5%–10% → 20%–30% → 50% → 100%, with 30 minutes to 2 hours per step; the whole process takes half a day to 1 working day.
• Strong consistency scenarios involving funds/inventory: gradually ramp up 1% → 5% → 10% → 20%, covering at least one reconciliation cycle (typically 1–4 hours, possibly T+1 for large amounts), and verify transaction amounts, counts, etc.

The typical gate for promoting to the next step: the error rate is no higher than the old version baseline of 0.3% and shows no upward trend; the P95 latency increase does not exceed 10%–15%; core business volume shows no continuous decline for 5 minutes. When business metrics are missing, compensate with log sampling or SQL reconciliation.

Four-step verification method: ramp up step by step without guesswork

1. Before ramping up, verify the canary scope and dependencies: confirm that the new version's table structure, cache keys, and third-party interfaces are ready, and the rollback entry is available.
2. Run a small-traffic smoke test at 1%–5%: specifically watch for startup errors, missing configurations, and dependency timeouts, for about 10–30 minutes.
3. Ramp up gradually in steps of 10% → 20% → 50%: use metric thresholds between steps; at 50%, also check capacity metrics such as connection count and message backlog.
4. After switching to 100%, stay on guard for 1–2 hours: focus on delayed scheduled tasks and asynchronous compensation anomalies.

In one delivery, the constraint was that monitoring only had basic alerts and no version-split business dashboard, while the new version changed the order discount calculation. We spent 15 minutes using SQL reconciliation to add key checks, and manually sampled real orders when traffic ramped to 20%. The cost was longer preparation for each release, but it avoided discovering a significant drop in payment success later. So when monitoring granularity is insufficient, add business verification scripts before talking about ramp-up pace. My experience range is: spending an extra 10–30 minutes per step on manual confirmation is much cheaper than letting a problem explode at 50% traffic.

This is also why it is not recommended to jump directly from 10% to 100%: capacity issues such as connection pool occupancy, cache penetration, and slow SQL often only become obvious at 30%–50% traffic. At small traffic, everything may look normal.

How should you choose between user-based, traffic-based, or region-based canary?

There is no absolutely optimal routing method. The key is whether the business flow can remain intact and whether a failure can be limited to a selected group of users. Whether the gateway supports hashing by user ID determines the canary mode. If only percentage weight is supported, first add API idempotency, then consider user-dimension canary.

• User ID hashing: the same user always stays on the same version, suitable for stateful flows such as login, cart, and payment; the downside is that traffic distribution may not be balanced.
• Traffic percentage routing: simplest to implement, suitable for stateless read APIs; however, a user might place an order on the new version but pay on the old version, so APIs need to be idempotent.
• Region or channel whitelist: convenient for internal trial runs and targeted feedback collection; but the sample may be biased and not representative of all users.

For fund-related flows, it is recommended to prioritize user ID-based canary so that the entire transaction stays within one version. If only percentage routing is available, the gateway must pass through the user identifier and perform idempotency and reconciliation at key nodes.

Applicability boundaries: when not to force a canary release

Canary is suitable for online services that can be routed by traffic or user identifier, where the new and old versions can be deployed independently and dependencies are compatible. Do not force a canary in the following situations:

• Emergency production fixes: when an incident has occurred, first roll back or apply full-rollout mitigation. After stabilization, follow up with canary regression.
• Destructive database changes: dropping columns or changing field semantics causes direct conflicts between new and old code, which a canary cannot hide.
• Client-side or embedded releases: limited by app stores or firmware upgrades, so they cannot be freely routed by server-side traffic percentage.

There is another often-overlooked boundary: if monitoring and logs are insufficient to distinguish traffic between new and old versions, or if there is no usable rollback entry, then the environment does not qualify for canary. Such environments should first improve release infrastructure rather than adding feature flags to the version.

FAQ

If canary traffic ramped to 10% with no errors, can I switch to full rollout directly?

Better not. 10% only indicates basic functionality works; it does not cover capacity or slow queries. It is recommended to continue observing at 20% → 50% steps, with at least 30 minutes per step; fund-related businesses should span a reconciliation cycle.

If there is no canary platform, does ramping on test machines count?

No. Canary must route traffic by percentage/user identifier through a gateway or load balancer. Test machines can only serve as a smoke test. First add routing and rollback entries, then perform production ramping.

If a few errors appear during the canary period, should I stop immediately?

It depends on the error ratio and impact scope. If errors are below the old version baseline and do not affect core flows, you can continue observing. If the ratio exceeds 0.5%, or fund/inventory issues occur, roll back to the previous step immediately. Do not gamble.

If the table schemas of the new and old versions are incompatible, can we use canary?

No, you cannot directly canary. Make the new version only add nullable fields or new tables to ensure the old version can still run. After the canary is complete, clean up separately. For destructive changes, use a downtime release.