CycleOps can now send alerts straight to your phone or favorite browser!

Push notifications work great alongside email alerts, so you can now add an additional, more familiar notification channel for top-up alerts, low balance warnings, memory threshold alerts, and other important updates without changing your current alert setup.

Note: The CycleOps team recommends setting up push notifications in addition to (not as a replacement for) email alerts

How to enable push notifications​

1. Sign in to CycleOps.
2. In the sidebar, open Settings, then select Alerts.
3. Find Push Notifications and turn on Enable push notifications on this device.
4. When your browser asks for permission, choose Allow.
5. Click Send test notification to confirm everything is working. Test notifications can take up to five minutes to arrive.

Push is enabled per device. Repeat these steps on each browser, phone, or tablet where you want to receive CycleOps alerts.

Set up push notifications on iPhone or iPad​

Apple supports web push for Home Screen web apps on iOS and iPadOS 16.4 or later. To enable it:

1. Open CycleOps in Safari.
2. Tap the Share button.
3. Choose Add to Home Screen.
4. Open CycleOps from its new Home Screen icon.
5. Open Settings → Alerts and enable push notifications for the device.

Tip: You can similarly enable push notifications on any smart phones (Samsung/Pixel/etc.) that allow for push notifications through home screen installed webapps.

Open an alert and take action​

Tapping a CycleOps notification takes you directly to the relevant account or canister. The alert opens with current data and a clear next step, so you can understand what happened and act immediately.

Manage your connected devices​

You can give each push device a recognizable name or remove devices you no longer use. Turning push off on one device does not interrupt alerts on your other connected devices.

Add push notifications to your own app​

CycleOps' push notifications feature is powered by research-ag's notification service, an open-source web push stack for Internet Computer apps. It includes a notification canister, a relayer for delivering browser notifications, a frontend SDK, and examples you can adapt for your own project.

If you want to bring push notifications to your app, visit the research-ag/notification-service repository for the integration and local development guide.

Ready to try it? Sign in to CycleOps, open Settings → Alerts, and connect your first device.

Memory costs on ICP are changing, and you might be thinking "what does this mean for my cycle bill"?

We were wondering the same thing, so we built a dedicated Memory Price Change view into CycleOps that teams can use to quickly understand the impact of the upcoming ICP protocol memory pricing update.

How does this affect my canisters?​

NNS Proposal #140538 proposes to increase canister memory costs on ICP by 2.5× (from $5 to $12.50 per GB/year).

While no implementation date has been set, we've provided a tool in CycleOps that you can use to better understand how this will affect your monthly canister costs.

How to view your projected memory cost increase​

Upon logging in, you should see a notification on the left-hand side of the app about your account's monthly memory cost changes.

Click on "View details" to see an account-wide and per-canister breakdown of your projected memory costs before and after the protocol changes take effect.

Account Wide & Per Canister Memory Cost Metrics​

Important: Data on this page is estimated. Protocol memory cost increases have been proposed but are not currently in effect.

The new memory cost page displays estimates on an account-wide and per-canister basis before and after the protocol change. Keep in mind that these estimates will change as new canisters are added and as existing canisters use more memory.

At the top, you'll find aggregated, account-wide monthly estimates for:

• Before/After memory cost
• Memory cost increase amount
• Total cycle costs (memory + compute), and the percent change in those monthly totals after memory costs increase

Additionally, you'll find a per-canister cost impact table sorted by canisters with the largest memory-related cost increase.

Closing thoughts​

While a 2.5× change sounds large in isolation, every application and canister has a different cost breakdown. Understanding projected costs can help you identify your most impacted services and realize future cost savings.

Have feedback or questions about the new memory cost tool? Reach out on X or in OpenChat.

We operate CycleOps and ICPTopup as a tiny distributed team (two founders and some contractors). Like most small teams, we've always had more product improvements queued up than we could get to. UI papercuts, customer-reported bugs, and small polish work can be the difference between a product that feels good and one that feels neglected.

Since February, we've been shipping 5-10 of these incremental fixes every week, with most of the work done by AI agents. We took a continuous improvement process we've been running for years and adapted it so that agents handle the heavy lifting while humans stay in charge of the decisions that require taste, product context, and long term engineering perspective.

This article is a walkthrough of how we moved this process to agents, what is working, and what we want to do next.

It Started With a Process We Already Had​

For a few years now, we've run an internal process we call "kaizen", borrowed from Toyota's philosophy of continuous, compounding improvement. The idea is simple: observe the product → spot issues → prioritize them → fix them → ship → repeat. We had it fully documented with four defined roles and a clear lifecycle that every issue followed.

When we started looking at what agents could take over, we didn't design a new system. We looked at our existing process and asked which of the four roles could be done by an agent. The answer was two: the project management work and the coding work. The other two (spotting issues and deciding what's worth fixing) stayed with humans, for now.

How It Works​

The Owner is anyone on the team who notices something off. You report it in Discord — a sentence or two is enough — and the system picks it up.

A customer reports a UI inconsistency in Discord. The Assistant bot deduplicates and creates a GitHub issue automatically.

The Assistant is an AI agent (his name is Canny) that acts as project manager. He lives in our Discord and watches for new reports. When one comes in, he creates a GitHub issue, checks for duplicates, and then goes and does the research a human PM would do: he pulls session recordings from PostHog, tries to reproduce the bug in a real browser, reads the relevant source code, and writes up acceptance criteria. Once he has a clear picture, he sends the Director a brief with a recommendation.

The Assistant presents an issue brief to the Director for review. A quick 👍 or 👎 keeps the pipeline moving.

The Director is human. They look at the Assistant's brief and decide: is this worth doing? This is where product judgment lives. Some issues are clear cut improvements, but some issues require additional design thinking.

The Contributor is another AI agent, this one focused entirely on writing code. It picks up issues that the Director has approved, reads the codebase, writes a fix, tests it in a browser, takes screenshots showing the fix works, and opens a PR. If the PR gets rejected, the issue goes back through the loop with feedback.

The Owner gets pinged when a fix is ready. Review the PR, merge, ship.

The Tools​

The Contributor runs on GitHub Agentic Workflows (gh-aw), GitHub's framework for running AI agents inside Actions. Everything is configured in markdown, agents run in sandboxed containers, and write operations go through approved outputs. We use Claude Code as the underlying model, which has given us the best results for well-scoped coding tasks.

The Assistant runs on OpenClaw, a self-hosted gateway that gives an AI agent its own computer. We need this for the Assistant because its job is broad—it browses PostHog, tests things in a real browser, manages GitHub issues, and messages people on Discord and Telegram. The nice thing about an agent with its own computer is that updating the process is as easy as sending it a message. Want weekly shipping reports? Tell it on Telegram. Want to change how issues get prioritized? Same thing. It updates its own protocols.

What We've Learned​

The process documentation was the hard part, and we'd already done it. Our written kaizen process (roles, lifecycle stages, decision criteria) essentially became the system prompt for the whole pipeline. If we hadn't documented this years ago for our own human team, setting this up with agents would have been dramatically harder. If you're thinking about doing something similar, start there.

Issue refinement is arguably where agents add the most value. Converting a one-line Discord message into a well-researched GitHub issue with reproduction steps, root cause analysis, and clear acceptance criteria used to cost us anywhere from five minutes to an hour per issue, depending on complexity. Canny handles all of that now. And the better the issue is written, the better the Contributor's code turns out, so this step compounds.

Humans currently need to stay on prioritization. Agents will cheerfully ship issues that lack fundamental product thinking. The Director role exists specifically to prevent that. Every issue gets a human review before any code gets written. As models improve and as our team more clearly understands the fundamental context problem, there should be less and less work for the humans to do at this step.

It doesn't need to work perfectly. The Contributor writes broken code sometimes. The Assistant loses track of issues occasionally. That's fine... the process has review cycles and human checkpoints that catch failures. Even at imperfect reliability, the throughput gain is massive.

Where It Falls Short​

Canny the OpenClaw agent in particular can be inconsistent, and we're experimenting with moving some of its responsibilities into more deterministic, purpose-built components.

The process is handling frontend fixes well, but we've intentionally restricted agents from touching our backend systems so far.

That said, for what it does cover, it's been worth it many times over. We're delivering a level of product polish that we genuinely could not achieve without this, not at our team size.

If you use CycleOps or ICPTopup and notice something that could be better, hit the feedback button. It goes straight into this pipeline, and you'll typically see your improvement shipped within a week (if it's actionable).

If you want to build something like this for your own team, we're happy to go deeper on the technical details. Feel free to reach out!

We’ve shipped a broad set of mobile UX improvements, and CycleOps is now genuinely easy to use on your phone.

Whether you’re checking cycles balances, responding to an alert, or doing a quick top-up, you can now do it comfortably on the go.

What we shipped​

A sweep of mobile-focused fixes across the CycleOps web app, including:

• Cleaner navigation and page layouts on small screens
• More usable tables, charts, and dashboards on mobile
• Improved forms and action flows (top-ups, canister actions, etc.)
• Better tap targets, spacing, and readability across the app

So often when you want to do “real work” in a mobile browser, you find unoptimized UIs are forced to bounce. We want to make sure this doesn't happen when managing your canisters on CycleOps.

Why it matters​

CycleOps is operational tooling. And operational tooling is most valuable when you’re not at your desk.

This update turns a bunch of “I’ll deal with it later” moments into “handled in 20 seconds” success stories:

• You notice something looks off → you can check it immediately.
• You’re mid-day, mid-errand, mid-anything → you can still take action.
• You want confidence that everything’s healthy → you can get it from your pocket.

How you can use it​

Open CycleOps on your phone and try the “real” workflows:

• Check cycles balances while you’re out at lunch
• Do a quick top-up during a walk or workout
• Deploy or manage a canister when you’re away from your laptop
• Keep building on ICP (and keep your canisters healthy) wherever you are

If you’ve never used CycleOps before: it’s a proactive canister management layer for the Internet Computer (monitoring, alerts, and top-ups) designed to reduce operational overhead and prevent surprise outages.

Try CycleOps:
https://cycleops.dev
https://icptopup.com

CI/CD pipelines just got a lot easier on the Internet Computer.

In this post, I'm going to show you how you can easily automate your deployments using CycleOps and IC Deploy Actions

No need to manually run dfx deploy command on your terminal, or spend hours configuring your custom github actions. Just plug in and use.

Hi there, I'm Steve Kimoi, an ICP developer behind tools like generate-did, DNS Config Generator, ckTokens Minter and other ICP developer toolkits.

Today I'm walking through how CycleOps pairs with the ic-deploy-actions GitHub Action to make Internet Computer deployments hands-off.

What We Shipped​

You can now easily automate your deployments to Internet Computer with these simple steps using ic-deploy-actions

• With just simple steps automation, you're sorted for life: combination of CycleOps with ic-deploy-actions helps you build & automatically deploy your canisters on every push.
• Secure auth: PEM keys are stored in GitHub Secrets, keeping credentials out of source control.
• Flexible workflows: you get to ship a single canister or multiple canisters within the same pipeline.
• Repeatable delivery: every merge to the default branch automatically updates your production code, thus making you stay consistent.

Why It Matters​

Manual deployments get messy when your project or team grows. This workflow keeps every step in GitHub, removes copy-paste scripts, and uses familiar GitHub Actions. What you merge is what goes live on mainnet.

How You Can Use It​

1. Create or Add a Canister in CycleOps​

• Spin up the canister from your CycleOps dashboard - full docs live here.
• Run a one-time deploy from your workstation so the canister has initial code on mainnet.

2. Wire Up ic-deploy-actions​

Create .github/workflows/deploy.yml in your repo and paste in this workflow:

name: Deploy to IC

on:
  push:
    branches: [main]
  workflow_dispatch:

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Deploy to IC
        uses: Stephen-Kimoi/ic-deploy-action/action@v0.1.1
        with:
          pem_key: ${{ secrets.IC_PEM_KEY }}
          network: ic
          canister_name: your_backend_canister_name
          deploy_frontend: "true"
          deploy_backend: "true"
          frontend_dir: src/your_frontend_dir/dist
          backend_package: your_backend_package
          frontend_package: your_frontend_package
          frontend_src_dir: src/your_frontend_dir

Generate a PEM key and add it to your GitHub secrets:

dfx identity new cicd-identity --storage-mode=plaintext
dfx identity export cicd-identity > cicd-identity.pem
base64 -i cicd-identity.pem > cicd-identity.pem.base64

Copy the Base64 output into a IC_PEM_KEY repository secret and you're done.

That's it - every push to main now ships straight to the Internet Computer. CycleOps handles monitoring and top-ups, while ic-deploy-actions keeps builds and deployments flowing.

✅ Ready to try it?​

1. Create a canister in CycleOps
2. Add ic-deploy-actions to your repo
3. Push to main and watch your deployment go live

Heap overflow anxiety — gone. The new CycleOps V3 Blackhole adds 8 new in-depth memory metrics, with heap and stable memory alerts that keep your canister's data healthy and cost‑efficient.

New Memory Metrics​

Every canister with monitoring upgraded to the V3 Blackhole now reports eight new memory fields, in addition to an aggregate total

The new memory fields tracked include

• wasm_memory_size - Tracks memory used by the WebAssembly module.
• stable_memory_size - Captures memory stored persistently across upgrades.
• global_memory_size - Monitors memory allocated for global variables.
• wasm_binary_size - Shows the size of the deployed WebAssembly binary.
• custom_sections_size - Reports the size of custom sections in the Wasm binary.
• canister_history_size - Tracks memory used by the canister's historical data.
• wasm_chunk_store_size - Measures storage used by Wasm chunking mechanisms.
• snapshots_size - Monitors memory usage by stored snapshots.

How Do these metrics help me?​

Different components of canister memory have different protocol limits. For example,

• Wasm (heap) memory size - 4GB (or 6GB for wasm64 canisters)
• Wasm binary size - 100MB
• Stable memory size - 500GB (can up to as large as the single canister limit)

Understanding these memory limits and using CycleOps to monitor and set appropriate alert thresholds allows you to:

• Catch leaks early: Get alerted immediately when heap or stable memory usage spikes.
• Save money: Track and optimize memory growth over time, saving on storage cycle costs.
• Avoid memory cliffs: Set proactive heap alerts to avoid hitting unfixable overflow errors and ensure smooth canister migrations.

What about email alerts?​

Quickly set up memory email alerts for individual canisters by clicking on the canister -> settings -> alerts.

Or for multiple canisters at a time by selecting a few canisters and pulling up the batch actions menu with (⌘ + K) or right click.

How can I upgrade?​

Each of these metrics provides deeper insight into memory distribution, helping teams optimize their canister deployments.

If you have any canisters that are eligible for a monitoring upgrade, you will be prompted to go through the upgrade wizard when you sign in. You can alternatively upgrade monitoring metrics with the batch actions menu or on the individual canister metrics page.

Continue reading here to learn more blackhole upgrades.

Today we're very excited to announce a new integration with icp.ninja, the web based integrated development environment (IDE) that is the best place to kick start your Internet Computer development journey. We built a new protocol and API that enables icp.ninja users to create, deploy, and manage real canisters, right from the IDE.

Introducing ICP Ninja​

We’re big believers in removing friction from the developer experience on ICP. You shouldn't need to think about token balances or manual top-ups just to launch your first app. When we connected with Georgi and the ICP Ninja team at DFINITY, it was clear we shared that same vision.

ICP Ninja gets it right. It lowers the barrier to entry, gives you the familiar IDE feel, and lets you start building fast. There was one limitation that it had, however. Until now, each deployment was temporary, only lasting a few minutes. While you could build, you weren’t really deploying on infrastructure you could keep.

That changes today.

Own Your Canisters​

With this integration, developers can now deploy canisters they actually own and control, directly from ICP Ninja. These are real, persistent canisters owned and controlled by you, ready to run production code.

Even better, they come with smart defaults. Every canister deployed through this flow is automatically monitored and configured with a top-up rule in CycleOps. If something goes wrong or cycles start running low, you’ll get a heads-up before anything breaks.

This matters. Canisters are the core building block for shipping software on ICP, and the fundamentals of how to maintain them should be easy and clear from the start. New developers shouldn’t have to learn the hard way. Best practices such as top-up rules should be built in, and that’s exactly what this release delivers.

Account Linking Protocol & Canister Management API​

To make this possible, we built an account linking protocol that securely links your ICP Ninja and CycleOps accounts with a one-time handshake. After that, all canisters published through ICP Ninja are automatically managed and monitored by CycleOps.

We also developed a new canister management API for 3rd party integrations. It provides read and write methods, so ICP Ninja can display live canister health, estimated runtime, and perform key actions like paying for new canisters or updating settings. Of course, for the full-on canister management experience, users will be directed to cycleops.dev.

If you’re building tools or dev experiences and want to tap into this API, reach out. We’d be happy to collaborate.

Go Ship Canisters!​

If you haven’t already, head over to icp.ninja and try it out. Create a project, link your account, write some code, and publish real canisters. You’ll get automation, monitoring, and best practices baked in from the very first deploy.

Spot the metric anomaly, trace it to a code update, and uncover the bug—your CycleOps dashboard just got x‑ray vision.

Today, we’re excited to announce a direct integration with Research‑AG’s canister History Tracker, allowing developers to connect memory spikes and cycle burn surges back to the exact deployments that triggered them.

What We Shipped​

CycleOps now integrates Research‑AG’s History Tracker for every canister in your account. 0 extra setup—just richer insights:

• Code revisions: view each WASM hash and its deploy timestamp
• Controller events: view additions & removals, with the actor who made the change
• Metric overlays: code change events are layered directly onto your cycle balance chart, making it easy to correlate metrics with code updates.

Why It Matters​

Correlate what changed with what broke (or improved):

• Memory spikes, cycle burn surges, latency drops—see the exact deployment that triggered them.
• Shared canister? Third‑party logs provide an immutable audit trail for controller changes, perfect for multi‑dev team ops or post‑mortems.

How You Can Use It​

1. Open any canister in your CycleOps dashboard.
2. Scroll to the Cycle Balance time series chart—history markers are auto‑overlaid.
3. Click History (top‑right) for a full chronological view, complete with diffable WASM hashes and controller metadata.

That’s it. New accounts get history tracking out of the box, and existing accounts already have it enabled—just refresh and explore.

Kudos​

Huge thanks to Timo Hanke and the Research‑AG team for building the History Tracker service, and for their support during the integration.

Ready to level‑up your observability? Get started with CycleOps today.

Have feedback? Join the conversation on OpenChat or tag us on X.

Today we're releasing the ability to create new canister smart contracts in seconds, and to manage them directly from your CycleOps dashboard.

No terminal. No dfx canister create ...<what args next?>. Just a few clicks.

What we shipped​

CycleOps now lets you create and manage Internet Computer canisters without ever leaving your browser. Add a canister and click “Create New” to:

• Create a canister on any subnet—including low‑latency, high‑storage, or fiduciary subnets.
• Pre‑load it with the exact number of cycles you choose.
• Add one or more controllers (your dfx principal, teammates, or service canisters).
• Manage lifecycle actions: start, stop, and delete.
• Tweak settings on the fly: controllers, freezing threshold, reserved cycles.
• Snapshot, restore, and stream live logs—straight from the UI.

Why we built it​

Creating canisters has typically meant juggling dfx, ledger transfers, and guessing which subnet will serve you best. That process costs time and invites mistakes:

• Speed: Spin up a production‑ready canister in seconds.
• Safety: Clear UI prevents accidental under‑funding or wrong‑subnet deploys.
• Scale: Fleet owners can keep all canisters—old and new—visible and actionable in one place.

CycleOps already monitors and tops‑up thousands of canisters; now it can create and manage them, too

How you can use it​

1. Open Canisters → New Canister in your CycleOps dashboard.
2. Pick the subnet that suits your use case. Need low latency? Choose one of our fast‑lane subnets. Want high node count for fiduciary workloads? That option’s there too.
3. Enter an initial cycles balance—CycleOps will transfer the cycles and confirm allocation.
4. Add controllers (paste principal IDs or pick from your org’s members).
5. Click Create. In a few seconds your new canister appears in the dashboard.

Managing Created Canisters​

After creating a canister, you can manage it by clicking on a canister and then navigating to its “Manage” tab. From here, you can:

• Start/stop the canister as needed.
• Adjust settings and controllers anytime.
• Snapshots: create a point‑in‑time state backup and roll back with one click.
• Watch live logs while you iterate.

Ready to try it? Log in and deploy your first canister today.

Have questions or feedback about CycleOps? Jump into our OpenChat or tag us on X.

Today, we're rolling out ICRC deposits for CycleOps, meaning you can fund topups directly from your SNS with a single Transfer SNS Treasury Funds proposal 🎉

Why we built it​

Some newer Internet Computer apps don't support the old "account ID" format for transfering ICP, prefering instead to use addresses in the newer ICRC format. Until now CycleOps payments only used the account ID format, which was a pain when using backwards incompatible APIs for ICP transfers (including the default SNS treasury management proposals).

CycleOps now provides your payment address in either format, so SNS's can fund more easily fund their CycleOps accounts directly from their treasury.

How do I find my CycleOps ICRC account?​

1. Navigate to the Billing -> Payment tab
2. Under "ICP Top-Up Account", click on Deposit
3. Select "ICRC Format", and copy your ICRC account

How do I send funds to my CycleOps ICRC account?​

1. Find and copy your accountl
2. Send funds to this account (Having trouble? See note below)

Ready to set up funding straight from your SNS treasury?​

1. Head over to your CycleOps dashboard to set up ICRC deposits for your SNS canisters.
2. Locate your your ICRC account
3. If using an application like SNS toolkit, directly copy in the full ICRC account.

Need help getting started? Find us @CycleOps on X and we'll guide you through the process.

Further reading​

Want to learn more about ICRC account formats? Check out the documentation on the ICRC-1 standard.

Did you know that your canister can suddenly stop saving new data if it’s on a busy subnet and you haven’t set it up to reserve enough cycles for new memory allocations?

CycleOps now has monitoring and alerting features to help you stay on top of the important but lesser-known "reserved cycles" canister configuration. Here's everything you need to know about reserved cycles, and how you can set up alerts for them in just a few minutes!

What are reserved cycles?​

Released in late 2023, the reserved cycles mechanism was designed to prevent a few canisters from easily consuming all the storage on a subnet. When a subnet is nearing capacity, canisters on that subnet must begin paying in advance for any additional storage and do so by automatically transferring some of their cycles into a dedicated “reserved cycles” pool.

Each canister can be configured to set a maximum size for its reserved cycles pool, which is known as a canister's reserved_cycles_limit configuration. All canisters have a reserved cycles limit of 5 trillion cycles (TC) by default.

What happens if I run out of reserved cycles?​

A canister which hits its reserved cycles limit will no longer be able to commit new state. This means that write endpoints will begin to fail, which can cause all sorts of production errors. You can see the types of execution errors that would occur in these instances in the official documentation:

• "Reserved cycles limit exceeded in memory grow"
• "Reserved cycles limit exceeded in memory allocation"

Introducing reserved cycles monitoring and alerting​

Our new features are designed to keep these reserved cycles errors from happening. Reserved cycles monitoring insights are available for all canisters monitored via the CycleOps blackhole version >= V2, the SNS, or the NNS and allow you to easily see if any of your canisters are approaching their limit.

Check out the Reserved Cycles Alerting documentation to configure reserved cycle alerts for your canisters.

By enabling these alerts, CycleOps will make sure that you receive ample notification before this type of production error hits your canisters. Don't wait for subnet load to break your canisters, set up your alerts now! It will only take a few minutes.

Further Reading​

This original forum post remains the best place for documentation on this feature if you want to dive deeper into the details. Have questions about reserved cycles? Ask a question on this thread, or ping us on X!

Connect with us​

Find us @CycleOps on X and let us know what metrics and alerts you'd like to see us build next!

Today we’re releasing even more tools to make it easier to manage your canisters. Batch actions have been live for a few weeks now, but with this release you can now change top-up rules, setup memory alerting, finalize canister setup, or perform a one-time top-up for hundreds of canisters at a time.

All you need to do is select a bunch of canisters, open the command prompt (⌘ + K) or right click, and choose which action you want to perform. Just one more thing we’re doing to make CycleOps the best possible home for your canisters.

What we built​

Did you know that you can right click your canisters to perform quick actions? The new CycleOps UI is built to be as intuitive as possible for canister newbies, and to provide flexible and fast tooling for power users. Today we are expanding these quick action menus with even more commands.

New Actions​

• Top-up now: Perform an immediate one-time top-up on a batch of selected canisters.
• Set top-up rule: Configure the automatic top-up rule for a batch of selected canisters.
• Add memory alert: Configure an email alert to be sent when a memory threshold is crossed for any of the selected canisters.

A home for your canisters​

Our goal is to make cycleops.dev the ideal hub for all your canister needs, from management to monitoring. These new batch actions are just one way we're making it easier for you to maintain and optimize your projects.

Connect with us​

Find us @CycleOps on X and let us know how these new tools are helping you streamline your operations!

Today we're announcing a core protocol update that will provide all canisters with more detailed memory metrics. This update equips developers with a clearer understanding of how their canisters utilize memory, allowing for better debugging, resource allocation, and monitoring.

This is our first contribution to the core protocol as a team, making CycleOps one of the first teams to contribute to the protocol outside of Dfinity, and aligns with our mission to help build a world class developer experience on ICP.

What's New?​

We've introduced new memory usage fields in CanisterStatus, giving developers a more granular view of memory consumption. These fields include:

• wasm_memory_size - Tracks memory used by the WebAssembly module.
• stable_memory_size - Captures memory stored persistently across upgrades.
• global_memory_size - Monitors memory allocated for global variables.
• wasm_binary_size - Shows the size of the deployed WebAssembly binary.
• custom_sections_size - Reports the size of custom sections in the Wasm binary.
• canister_history_size - Tracks memory used by the canister's historical data.
• wasm_chunk_store_size - Measures storage used by Wasm chunking mechanisms.
• snapshots_size - Monitors memory usage by stored snapshots.

Each of these metrics provides deeper insight into memory distribution, helping teams optimize their canister deployments.

Why Does This Matter?​

Gain a new level of transparency into canister memory usage.

Understanding canister memory usage is crucial for:

✅ Better Debugging - Identify memory-intensive operations and optimize them.
✅ Improved Resource Management - Allocate cycles more efficiently based on memory consumption.
✅ Enhanced Monitoring - Provide more granular insights into canister behavior.

For teams using our monitoring solutions, these updates complement our existing cycle tracking and performance analytics, making it easier than ever to track and optimize memory usage.

A Collaborative Effort​

This improvement was the result of a fantastic collaboration with the teams at Dfinity, and we're grateful for the opportunity to contribute to the IC ecosystem. Open-source progress thrives on shared efforts, and we're excited to continue pushing the platform forward.

Got thoughts or feedback? We'd love to hear how these new metrics help you optimize your canisters! 🚀 Connect with us and share your experience @CycleOps on X

References​

• Interface Spec PR
• Commit a944a8b

Today we're releasing icptopup-ts, a TypeScript package that makes it easy to programmatically 👨‍💻 facilitate large amounts of decentralized compute, sending cycles to up to 100 canisters at at time.

With npm install icptopup-ts, you can integrate atomic, ICRC compatible cycle topups into your application in just a few minutes!

How can I use icptopup-ts?​

👉 To get started, head to the icptopup-ts installation instructions ✍️

The package comes with both synchronous and asynchronous primitives for sending cycles depending on your desired UX, and slots in easily to both Frontend and NodeJS contexts 🎉

Over the past few weeks, developers have already used icptopup-ts to mint and send over 30,000T cycles across more than 21,000 individual canister topup events.

Why did we build icptopup-ts?​

Before icptopup-ts, converting ICP to cycles had the following issues:

1. Minting cycles from ICP is not atomic and requires both an ICP transfer request, followed by a request to burn that ICP in order to mint cycles. Therefore, a topup attempted by a frontend integrated with the CMC could leave a user initiated topup in a half-finished, or inconsistent state, such as having sent funds but not received a topup if something goes wrong in the middle of this process.

2. The Cycles Minting Canister (CMC) was not ICRC compatible. By not supporting ICRC transfers, funds held in ICRC accounts required two transfers (one to a non-ICRC account, and then another to the CMC) in order to facilitate an ICRC topup, creating non-atomic asynchronous complexities, and introducing additional potential points of failure to a topup.

3. The CMC does not have a batch cycles minting API, meaning that the developer needs to handle all complexity associated with batching cycles, incurring additional, unnecessary fees for each individual cycles minting transaction.

icptopup-ts solves these issues by providing a simple, atomic, ICRC compatible API for topping up multiple canisters in parallel.

Using ICRC-2 Approvals to simplify the DX 💪​

The package leverages ICRC-2 approvals, allowing the icptopup API to handle both ICP transfer and cycles topups, as well as handling any potential intermediate error states that could occur. This results in a simplified, decoupled two step experience:

1. First, the developer approves icptopup-ts to mint cycles. This step is a simple approval for funds to be transferred, and does not transfer any ICP.

2. Then, the developer makes a single API call to execute the multi-canister topup. This single API call executes both the ICRC-2 ICP transfer and well as the cycles minting action.

How does it work?​

Under the hood, icptopup-ts is built on top of the ICPTopup Service, integrating with fixed APIs on the backend ICPTopup canister. The ICPTopup canister provides unified, atomic topup APIs that handling ICRC ICP transfer, cycle minting, and parallel batch cycles distribution to canisters.

What's next?​

We're looking forward to seeing what you build with icptopup-ts! If you have any questions, requests, or feedback, file an issue or reach out to us @CycleOps on X.

Starting today it's easier than ever to manage a large fleet of canister smart contracts on ICP. We're releasing a new UI for cycleops.dev that can handle hundreds (or even thousands) of canisters, and we've raised our per account canister monitoring limit from 30 to 1,000. Already, teams have integrated fleets of up to 800 canisters for monitoring, alerting, and automated top-ups.

Our mission at CycleOps is to bring ICP's decentralized compute to market by providing a world class developer experience, and managed solutions for the biggest pain points of builders large and small that want to build on the future of the decentralized web. Making it easy to control large fleets of canisters is a big step in that vision, so let's take a closer look.

Adding Your Fleet​

So you've got a fleet of canisters. How can you connect to CycleOps to get monitoring, alerting, and automated top-ups? I have good news for you: it will only take 5 or 10 minutes, plus a few minutes of running an automated script.

Our CSV upload feature has you covered. All you need to do is create a spreadsheet that lists all your canisters and how you want them to be configured. Don't worry about strictly formatting it, the upload feature will map it into the expected format and allow you to proofread and fix the mapping if necessary. Read the docs for more detail about what columns you can use to customize your CycleOps configuration when adding the CSV upload feature.

Monitoring Your Fleet​

So you've successfully added your fleet, what can you do now? After adding your canisters, you'll have be able to see basic information. CycleOps monitors canisters on a six hour interval, so within a day you'll start to see valuable time series data accumulate for your canisters.

For each canister, CycleOps provides a deep dive view that includes time series metric charts from query calls to your canister, to cycles balance, cycles burn, amount spent on top-ups, and memory usage. You'll also see metrics like current canister health & controllers, as well as estimated time until freeze, next estimated topup, etc.

Your dashboard displays aggregate metrics for all of your canisters, so you can easily see if all your canisters are healthy, how many cycles they're burning and how much you're spending on top-ups.

You can personalize the display of data that's displayed for each of your canisters on the dashboard. By default your dashboard will display burn rate, cycles balance and memory size, estimated freeze date, and more. Perhaps you want to show an estimated next top up for each canister, or the subnet that the canister is deployed on. By clicking on "Display" and choosing a configuration, you're in control.

Bulk Canister Actions​

Working with large fleets of canisters means being able to manipulate them in large batches, and the new CycleOps dashboard UI makes that very easy. You can right click on any canister to edit it, or select a group of canisters to perform an action on the entire set.

As of this release we support batch actions for editing tags and projects. More actions are planned and in development for changing top-up rules, setting memory alert thresholds, sending one-time top-ups, and many other things that you can do on a single canister in CycleOps.

Keyboard Navigation​

The dashboard also supports native-like keybinds for selecting canisters, and action specific keybinds.