How Kulu cut its observability bill by 80%

Kulu ran entirely on AWS, with observability split across two tools.

That left engineers with two places to look and two vendors to pay, and both tools price by volume. Kulu generates about a billion signals a day, and its CloudWatch spend alone ran at $50–75 an hour, before anything it paid Datadog.

Kulu also needed things neither tool offered out of the box. Fargate's built-in log routing sends logs to AWS services such as CloudWatch, which tied Kulu's logs to the same metered service it was trying to spend less on. Its business team needed to hear about operational events, such as a wallet balance running low, in a form they could act on.

Kulu is built for market vendors, moto-taxi drivers, and others taking payment by QR code, many of them outside the formal financial system. A failed or slow payment can cost them a sale and cost Kulu their trust, so every endpoint needs watching. Each new region Kulu reaches beyond Conakry also adds to its signal volume and to the bill that comes with it.

Kulu also had obligations any monitoring setup had to respect. E-money services in Guinea operate under the supervision of the Central Bank of the Republic of Guinea (BCRG), and Kulu handles personal and financial data under Guinea's 2016 law on cybersecurity and personal data protection.

Infrastructure, metrics, logs, and traces now run through Scout, base14's unified observability platform, as one correlated system. Engineers no longer switch between CloudWatch and Datadog to piece together what happened to a payment.

Kulu now spends roughly $11 an hour on observability. Against CloudWatch alone, which ran at about $440K–660K a year, that is a reduction of 77–85%. Kulu was paying Datadog on top of CloudWatch, so the real saving is larger.

Scout's per-signal pricing accounts for part of the saving. The rest came from cleaning up the data: base14's engineers worked with Kulu to find and remove duplicate logs, so Kulu stopped storing the same events twice.

base14 built a way to ingest logs from Kulu's applications on EKS Fargate straight into Scout, without routing them through CloudWatch or any other AWS service. Logs no longer pass through a second metered service before reaching the place engineers read them.

Kulu runs around 2,500 alerts that watch error rates and latency on every API endpoint, set up through SLI alert templates. Alerting is included in Scout with no per-alarm fee, so the number of alerts doesn't change what Kulu pays.

Kulu's business team has its own access to Scout and works from dashboards that track commissions, wallet balances, and payments. Engineering and business read the same data, and because Scout doesn't charge per seat, adding the business team added nothing to the bill.

base14 built a custom HTML email templating mechanism so Scout can send alerts to the business team in plain language. When a wallet balance runs low, for example, the business team gets an email asking them to recharge it, without anyone in engineering having to pass the message on.

Kulu's engineers also use Scout MCP, which lets their AI assistants query live telemetry in natural language, including traces, logs, metrics, and service topology. When a question is quicker to ask than to write a query for, they describe what they're looking for and get the data back.

Telemetry from a payments app carries personal and financial data, so Scout's controls had to fit Kulu's obligations. Scout processes and stores each tenant's data in isolation, encrypts all data in transit, and offers retention beyond the 30-day default. Inside base14, access to production data is off by default, any temporary access is time-bound and audited, and engineers see only anonymised or scoped-down data when debugging.

base14 engineers still meet Kulu's team every two weeks, so instrumentation, dashboards, and alerts keep up as Kulu changes. Kulu recently moved its workloads from EKS Fargate to EKS managed nodes to cut infrastructure costs, and its observability on Scout moved with it.