I’ve been using CycleOps recently and noticed something a bit confusing. It seems like the number of cycles shown in CycleOps is sometimes less than the actual number of cycles present in the canister.
Has anyone else experienced this issue? Does CycleOps filter out or hide some cycles under certain conditions?
Also, is there a proper tutorial or detailed explanation available for how the CycleOps dashboard works, especially how it calculates and displays cycle usage?
Any help or pointers would be greatly appreciated!
Thanks in advance!
Every inflight message reserves a large number of cycles. If you have a large polling operation you may have trillions of cycles withdrawn for short bursts. If it reads during this time then you may get those refunded after everything returns.
CycleOps monitors cycles balances and records canister metrics data points on a regular time interval. So there’s often a delay between what your canister’s metrics are at this instant, and what CycleOps shows.
If you send cycles to a canister within CycleOps, it will record a new data point before and after the topup and give you the most recent data, but if you send cycles to that canister externally (outside of CycleOps), then there may be a period of time where we don’t have the most recent data. This would result in a canister’s CycleOps balance showing as lower than the actual balance. It also would result in a less accurate cycle burn rate estimate for that canister.
You might find other articles in the changelog helpful for staying up to date on our latest features, such as reserved cycle alerts and batch actions.
Are there any specific questions you have regarding how the CycleOps dashboard works?
CycleOps monitors your canisters on a periodic interval and records all sorts of metrics, from cycles balance to memory, query calls, etc. By recording multiple cycle balance measurements over time, we’re able to provide per canister cycle burn estimates, as well as aggregate metrics for all the canisters in your account.