How Anton built its entire incident response in 15 hours using Rootly's Terraform provider.

Anton Payments is AI-native cross-border payout infrastructure. Built around Anton Intelligence, every transaction is risk-scored, compliance-checked and intelligently routed before it moves, across more than 170 countries, for marketplaces and enterprise platforms.

Founded: 2026 in Burlington, Ontario, Canada

Stage: early access

Availability target: four nines

Ryan Olson spent two and a half months trying to build his own incident response. Two hours a day, six days a week — first across Google Cloud’s logging and uptime tooling, then PagerDuty, then a custom build on Twilio. He could have made it happen. The question was whether it was worth it. He is Anton’s founder and CEO, and at the moment he is also its CTO, its COO and most of the rest of the C-suite, so that time came out of everything else he needed to do.

Then a friend suggested Rootly. Twenty minutes later he had decided. Fifteen hours after that, his entire incident response was running, defined in Terraform alongside the infrastructure it protects.

“Rootly is the only incident management platform that I could express the entire configuration in Terraform without fighting it.” —Ryan Olson, Founder and CEO

When every second is somebody’s payroll

Anton exists to move money, which means downtime tolerance isn’t a preference. It is the product. The moment you are touching a dollar, a euro or a peso, Ryan says, every fraction of a second matters — for reasons ranging from foreign exchange to time of day to simple urgency. He puts the stakes more plainly: if your payroll did not arrive on time, how angry would you be?

So he built for that. Anton runs on four nines across three clouds — Google Kubernetes Engine, AWS in Europe and Azure in Toronto — with automatic failover to a second region and a third infrastructure held on standby.

The resilience was never the problem. Knowing was.

If a SQL or Redis cluster failed, Ryan knew the system would fail over. What he couldn’t guarantee was learning about it fast enough to prevent what followed: data inconsistencies, a cascading failover, latency creeping into transaction processing, or trouble in the compliance layer.

He tried to solve it with what he already had — Google Cloud logging, storage buckets, streaming data services, uptime pings, the lot. His assessment is that Google is very good at hardware infrastructure and acceptable at the rest. Nothing was lost, not the logs and not the streaming audits, but none of it arrived in real time at the resolution he needed.

Worse, heartbeats and pings are inherently subjective. Two or three times a day, something would report his API down when it was not. An alerting system that cries wolf twice a day is not an alerting system.

“Rootly tells me the moment something goes wrong, and it knows the difference between noise and a real incident.” —Ryan Olson, Founder and CEO

Twenty minutes to decide, fifteen hours to build

The alternatives did not survive contact. PagerDuty, in Ryan’s blunt assessment, was painful to configure. A custom build on Twilio was entirely possible — he reckons a week — but it meant committing to real recurring cost, minimum commitments and service levels for a system that might never trigger. Two and a half months in, he had spent something close to 150 hours and had nothing he trusted.

A friend at another company suggested Rootly. The decision took twenty minutes.

Ryan writes Terraform the way other people write email. He likes a story that makes the point: he once deliberately destroyed his entire network — sandbox, staging and production clusters across every region — then rebuilt it all from Terraform and watched it come back.

So when he found that Rootly’s configuration could be fully expressed in Terraform, the same language that builds his infrastructure, his IAM protocols, his rules and his identity tooling, the evaluation was effectively over. He describes Rootly as the only provider in the category offering full, easy-to-use Terraform configuration.

That is not only an aesthetic preference. For companies where small teams hold most of the technical knowledge, configuration as code is continuity insurance.

Fifteen hours later, the entire integration was live.

Incident response that lives in the same configuration as everything else

This is the heart of it. Anton’s infrastructure, identity protocols, access rules and now its incident response are all defined in one language, in one place, version-controlled together. When Ryan changes how his system is built, the thing that watches it changes in the same commit.

For a technical founder, that removes an entire category of drift — where monitoring quietly stops matching the system it is supposed to be monitoring.

Compliance stays separate and is wired into the core

This is the part most incident tooling never considers, and for a regulated payments business it is not optional.

When something goes wrong at Anton, engineering and product need to fix it, operations needs to reassure customers, and compliance needs to establish whether anything happened that must be reported to regulators in Canada, the United States, Europe, the UK, Australia, Brazil, Argentina, Mexico and beyond. Those are three different audiences with three different clocks.

So Anton built compliance its own rule set. A 2am incident does not wake the compliance team, but the moment they pick up their phones at half past seven, a full account is waiting — triggering the internal processes that follow, including the reports that may need filing.

The 2am test he did not mean to run

Ryan started sleeping well at night by accident.

Late one night, changes he was making in a test environment caused Rootly to alert immediately that something had direct access to the database, outside a core Google policy. It was him.

What he did next is the whole point of buying an incident platform. He stopped working and went to bed, because he knew that if anyone reached his system, he would be woken up.

Spend a lean team avoids by not staffing the night

On current usage, Ryan expects to avoid around $150,000 a year, growing annually — principally because a reliable on-call structure costs far less than dedicated overnight engineering cover, which he does not have to hire for.

Looking further out, he projects that not hiring one to five engineers over three years could take that toward half a million a year by year five. He also forecasts faster resolution, somewhere in the range of a third quicker, as the platform separates noise from genuine incidents and exposes data to everyone at once. And he points to avoided regulatory exposure on serious incidents, which he puts in the thousands to tens of thousands per event.

“Since I set it up, I have forgotten about it. I know it’s there and I know it works well. That’s what you want from your reliability platform.” —Ryan Olson, Founder and CEO

A system that moves other people’s money comes with particular exposure, and Ryan and the team built it the way good engineers do: redundancy across multiple regions and three clouds, on four nines.

What he couldn’t build, after two and a half months of trying, was the part that tells him when something has gone wrong and makes sure the right people know, on the right timeline — including the ones who have to answer to regulators. That took fifteen hours once he found a platform he could define the same way he defines everything else.

The cost avoidance he can put a number on is the overnight coverage he doesn’t have to hire. The one he cannot is that he goes to bed and sleeps soundly.