I was hoping that the OP provides some feedbacks, in order to be on the same page so that I can write a very short answer. But, never mind.
I will try, by a analogy, to illustrate the type of pitfalls one should avoid when working on clock requirements in GNSS.
Assume my neighbor has a very expensive Rolex watch and I bought my wife a cheap copy. Then my wife complains that she observes that her watch loses 1 second every day compared the neighbor’s. After one month, it is now 30 seconds late. Should she throw it away after a month? NO! I would explain that she has a very accurate time-keeping system, as accurate as our neighbor’s Rolex. As her watch loses EXACTLY one second per day, she can derive the EXACT and same time shown on the Rolex for ANY day, and this eternally (no aging).
And this is how time-keeping works in GNSS. You have an absolute reference on-ground. The Control Center measures the drift of each satellite clock with respect to the reference, then derive a prediction model to cancel the errors. The computed parameters of the error model are then broadcast by the satellite (together with the ephemeris) in the Navigation Messages. It is these parameters that are updated when needed, not the satellite clock per se (the user receivers make the correction). All GNSS system I know of (GPS,GLONASS, GALILEO, BEIDOU, QZSS,…) follow the same strategy (and basically the same prediction model).
The residual error, after each prediction update, is due to many noisy short-term factors (but not drift and aging, as long as these are still PREDICTABLE). BTW, the contribution of the satellite clock residual errors to the user positioning accuracy is ~ 2m for GPS (civilian service). Other error sources (mainly the ionosphere and the geometry) contribute to the rest of the often quoted 10m performance (in absence of multipath).