At 14:02:20, the control plane shows a familiar shape: request volume is still below the customer’s recent peak, but the slope has changed. Several consecutive intervals are rising faster than the traffic history normally allows. The edge nodes have not reached saturation. The spike has not peaked. Forty seconds remain before the wave reaches its highest point.
That is the operating window our traffic prediction model is built to identify. Its output can trigger a capacity shift before the demand arrives, without requiring an SRE to watch a dashboard or approve every action. Across early-access pilots, the model flags incoming spikes 40 seconds ahead on average.
What the model is trained on
The model is trained on the customer’s own traffic history. This is the central design decision. Traffic patterns vary significantly between workloads, and a generic baseline can mistake normal behavior for an anomaly. A workload with regular campaign launches has a different definition of “high traffic” from a service with a flat weekday profile and occasional bursts.
Customer-specific history gives the model a reference for the workload it is actually serving. It can distinguish a known recurring increase from a departure in the observed pattern, then produce an output that the control plane can use for capacity decisions.
No tuning is required from the customer. There is no parameter set for an application team to maintain and no separate forecasting workflow to operate. The model is part of the control plane, so its result is available where capacity shifting is coordinated. It does not run at the edge node level.
That placement matters. A prediction made independently at each edge node would have a narrower view of the service and could produce inconsistent decisions across locations. The control plane has the position needed to turn a traffic signal into a deployment decision. Symbiosis currently operates 12 PoPs across 5 continents: Stockholm, London, Amsterdam, Frankfurt, Paris, New York, Chicago, Los Angeles, Sao Paulo, Singapore, Tokyo, and Sydney.
From prediction to capacity shift
The model is not an alerting layer that hands a recommendation to a person. Its output is connected to capacity shifting in the control plane. When the predicted traffic pattern crosses the relevant operational threshold, the platform can begin shifting capacity before the spike peaks. No human is in the loop unless the customer wants one.
This distinction changes the timing problem. Reactive scaling waits for an observable condition such as increased utilization or request pressure. By that point, the system is responding to demand that has already arrived. Prediction creates a lead-time budget. In our case, the average is approximately 40 seconds, which gives the platform time to act while the traffic curve is still rising.
That lead time is not a promise that every event will be handled identically. It is an average observed across early-access pilots. The actual window depends on the traffic pattern and on whether the incoming event resembles the history available to the model.
A synthetic example: a campaign launch
Consider a synthetic e-commerce workload with a recurring product campaign. The team has run similar launches several times, so its traffic history contains a recognizable increase around the campaign start. On a new launch day, the control plane sees the curve begin to diverge from the recent baseline.
At T minus 60 seconds, the increase is visible but not yet actionable. At T minus 40 seconds, the model flags an incoming spike. The traffic is still climbing, and the peak has not arrived. The control plane uses that output to trigger a capacity shift. At T plus 0, the campaign reaches its highest demand. The system is no longer trying to add capacity after the peak has already created pressure.
This is a deliberately simple example. The useful property is not that the model knows a campaign exists. It is that the customer’s prior traffic history supplies a reference for the shape and timing of demand. The model works with the workload’s observed behavior rather than requiring the application team to describe every future event manually.
Serving constraints matter as much as the forecast
A forecast is only useful if the surrounding platform can act within its lead time. We therefore measure the complete path from model output to infrastructure response, not just the prediction itself. The control plane must receive the output, make the capacity decision, and coordinate the resulting shift across the relevant deployment footprint.
Cold-start performance is another part of that path. Across early-access pilots, Symbiosis has measured a 14ms average cold-start. That number does not describe the model’s 40-second forecasting window. It describes how quickly a workload can start when the platform needs to place or activate capacity. The two measurements answer different questions: prediction asks when demand is coming, while cold-start asks how quickly capacity can become available.
Customers can inspect the surrounding behavior through the integrations we provide for Datadog and Grafana. Those integrations are useful for comparing the prediction signal with the traffic and capacity events that follow it. They also give teams a way to review cases where the model acted earlier or later than expected.
Where the model is wrong
We are not saying this model is infallible. We are saying that customer-specific traffic history can provide a useful operational head start, with an average lead time of about 40 seconds in early-access pilots.
The difficult cases are the events with little or no precedent in the history. A completely novel launch, an unexpected external referral, or a sudden change in application behavior may not resemble the patterns the model has seen. A spike can also arrive faster than the available lead time, leaving less opportunity for a capacity shift. Conversely, a false positive can identify a rising pattern that does not develop into a large peak.
Those cases are why the prediction output should be evaluated alongside traffic and capacity telemetry. The model is a control-plane input, not a replacement for understanding the service. Teams that want human approval can keep a human in the loop. Teams that do not want that operational step can allow the platform to act automatically. No SRE is required to operate the prediction path.
What we optimize next
As a three-person team, Buster Styren, our CEO and Co-Founder, Elias Makinen, our Head of Infrastructure, and I have kept the model focused on one measurable job: identify an incoming traffic spike early enough for the control plane to shift capacity.
That focus also keeps the product boundary clear. AI traffic prediction is included in the Starter tier at $29 and the Pro tier at $89. It is not included in the Hobby tier. The model runs as part of the platform rather than as a component that customers have to deploy, tune, or monitor independently.
The most important observation from building this system is that forecast quality and infrastructure timing cannot be separated. A 40-second warning has value only when the platform can convert it into a capacity action during those 40 seconds. That coupling between the traffic signal and the control plane is where the prediction model becomes an infrastructure feature rather than another chart.