Building Sentinel: How We Monitor the Chinmay Finlease App, Our Lending APIs, and Our Servers in Real Time

By the Chinmay Finlease Engineering Team

Contributors: Namra Parikh, Malav Dalvadi, Mukund Patel, Harshil Patel, Rahil Patel

Introduction When a borrower opens the Chinmay Finlease app, two things have to work perfectly: the app in their hand, and the dozens of services behind it that turn a loan request into money in a bank account. If any link in that chain slows down or breaks, the borrower feels it long before we do.

For years, our monitoring stack kept the lights on the way most growing fintech teams do: logs in one tool, server metrics in another, app crashes in a third, and a human somewhere expected to notice. It worked until it didn’t. Our most reliable outage detector was a customer complaint.

The result of rebuilding that stack is Sentinel, a real-time, AI-assisted monitoring system that watches our three critical surfaces (the Chinmay Finlease app on Android and iOS, the lending and integration APIs behind it, and the servers underneath both), routes every incident to the team that owns it, and, when no one responds, picks up the phone and calls an engineer. Since rolling it out, we detect the large majority of incidents before a single support ticket is filed.

In this blog, we share the engineering decisions behind Sentinel, the trade-offs we deliberately made, and a few things that surprised us along the way. Monitoring at Chinmay Finlease A single loan disbursal touches a surprising number of systems: the mobile app, our loan origination backend, KYC and verification APIs, payment gateways, and the databases and servers tying them together. Each of these already emitted logs, metrics, and errors. The raw signal was never the problem.

The problem was attention. That signal was scattered across separate tools, owned by no one in particular, and visible only to whoever thought to go looking. A dashboard sitting on a wall is not monitoring; it is monitoring that depends on a human remembering to look. At 2 AM, nobody looks.

This is the layer that sits upstream of everything a borrower experiences. A slow verification API doesn’t just slow one screen, it stalls every application flowing through it. A bad Android release doesn’t affect one user, it affects everyone on that version until someone notices. At our scale, the gap between “something broke” and “someone knows something broke” is where trust is lost.

Design Goals for the New System Our old approach was simple and cheap: fire an alert when a metric crosses a fixed threshold, email it out, and hope someone reads it. As we grew, we increasingly cared about three situations it handled badly:

• Fast-moving incidents, like a bad release or a degrading upstream API, where minutes matter and email does not.
  

• Ambiguous signals, where one error is noise but fifteen of the same error in three minutes is a fire, and a static threshold can’t tell the difference.
  

• Off-hours failures, where the person who needs to act is asleep and a Slack message will sit unread until morning.
  

Meeting these called for a system that could learn what “normal” looks like, route problems to a clear owner, and escalate on its own when humans went quiet. That framing drove every decision that followed. Two Decisions That Shaped Sentinel Before building anything, we made two calls that traded a more elegant idea for something that would survive in production. Decision 1: Baselines, Not Thresholds The obvious design is a static threshold: alert when latency crosses X or error rate crosses Y. In theory it’s simple and predictable.

In practice, thresholds break every time reality shifts. Traffic doubles and the threshold is suddenly too low. A new app version changes behavior and the threshold is suddenly wrong. Someone tunes it up to stop the noise, and now it never fires. Static thresholds don’t fail loudly, they fail quietly, by crying wolf until people mute the channel.

So Sentinel learns a baseline for each thing it watches (per platform, per app version, per API) and alerts on deviation from that baseline rather than a fixed number. This is more work up front, but it’s the single decision most responsible for people still trusting Sentinel’s alerts months later. Decision 2: Suppress Aggressively, Even at the Risk of a Miss The instinct when building monitoring is to forward everything: every error, every blip, to be safe. We rejected that too.

The real enemy of monitoring isn’t a missed error, it’s alert fatigue. Every alert a human glances at and ignores trains them to ignore the next one, and eventually they ignore the one that mattered. So we deliberately send less. A single bad event is logged silently. Only a pattern (a cluster, a sustained deviation, a spike against baseline) becomes an incident that pings a human.

We spend more engineering effort deciding what not to send than what to send. It is counterintuitive, and it is the reason the system works. How Sentinel Works With those decisions locked, Sentinel funnels every critical system into one pipeline: events are classified by service and severity, enriched with context, and routed to the owning team’s Slack channel, never a generic #alerts graveyard. Here is how that plays out across our three surfaces. The Chinmay Finlease App (Android and iOS) Every error a user could hit (app crashes, backend exceptions, failed API calls, payment gateway timeouts, KYC step failures) flows in real time, tagged with platform, app version, and the exact journey step where it occurred. An Android crash routes to the mobile team; a disbursal API failure routes to the backend team. Each alert arrives with the stack trace, the affected screen or endpoint, recent release history, and the number of users impacted, the ten minutes of context an engineer would otherwise gather by hand.

Platform is a first-class dimension here. The same release can run perfectly on iOS and break on one specific Android version, so error rates are tracked per platform and per version against their own baselines. A spike right after a release surfaces within minutes, not after the Play Store reviews arrive. The Lending and Integration APIs Behind every loan sits a chain of APIs: our own lending and origination services, plus the third-party integrations we depend on for KYC, credit bureau pulls, bank account verification, and disbursal. A borrower’s application is only as fast as the slowest link in that chain, and most of those links are outside our four walls. Sentinel monitors each API individually: success rates, latencies, error signatures, and queue depths, each against its own baseline. Third-party providers are the most volatile dependency in Indian fintech; they degrade, throttle, and change behavior without warning. When one API’s success rate dips or its latency climbs, the owning team is alerted with the affected API, error signature, and live impact count, early enough to reroute, retry intelligently, or switch to a fallback provider before applications start piling up at that step. The same alert arms our operations team, so when disbursals slow down, the reason is already on the screen instead of buried in a vendor’s status page. Servers and Infrastructure Underneath all of it sits classic infrastructure monitoring (CPU, memory, disk, database health, and uptime probes) on the same Slack-first spine with severity-based routing. On top, Sentinel adds correlation: rather than firing three separate alerts for a server load spike, a slow database, and a growing request queue, it increasingly recognizes them as one incident with three symptoms and points the team at the likely root cause instead of the loudest side effect. The Part That Surprised Us: Slack Isn’t Enough We built Sentinel assuming that routing every incident to the right Slack channel, with full context and clear ownership, would be enough. During the day, it was. Response times dropped sharply the moment ownership became unambiguous.

Then we watched what happened at night. A critical alert would land in exactly the right channel, with everything an engineer needed to act, and simply sit there. The system had done its job perfectly. The human was asleep. Perfect routing means nothing if the destination isn’t looking.

The fix was to stop treating notification as the last line of defense and make a conversation the last line instead. Our Solution: AI Call Escalation When a critical alert goes unacknowledged past its response window, Sentinel doesn’t wait. It places an AI voice call to the on-call engineer. If they don’t answer, it walks up the hierarchy: the next person in the escalation chain is called, then the one above them, until a human acknowledges the incident.

This closed the one gap that context and routing couldn’t. An alert can be missed; a phone that keeps ringing its way up the escalation chain cannot. It has quietly become the piece of Sentinel the team trusts most, precisely because it assumes something will eventually be missed and plans for it. Impact Since rolling Sentinel out across all three surfaces, the change has been less about any single metric and more about a shift in how problems reach us:

• The large majority of incidents are now caught before a support ticket is filed.
  

• Time-to-acknowledge for critical incidents dropped sharply once every alert carried a named owner and an escalation path.
  

• Post-release regressions on specific Android versions are caught in minutes, before they spread across the user base.
  

• Off-hours critical incidents no longer wait until morning, because the system calls until someone answers.
  

The clearest way to see the difference: before Sentinel, our fastest path from “a system broke” to “the right engineer is fixing it” often ran through a frustrated customer. Now it runs through a phone call the customer never sees. Conclusion A few lessons from building Sentinel that we’d carry into any monitoring system. Baselines Beat Thresholds A threshold is a guess about a world that keeps changing. Learning what normal looks like, per platform, per version, per API, and alerting on deviation is what lets a monitoring system grow with you instead of being retuned every month. Suppression Is a Feature The hardest engineering in monitoring is deciding what not to send. Every ignored alert erodes trust in the next one, so aggressive suppression, treating one bad event as noise and only a pattern as an incident, is what keeps alerts worth reading. Ownership Beats Visibility A dashboard everyone can see is a dashboard no one owns. The moment every alert landed in a specific team’s channel with a name attached, resolution times fell, without a single change to detection. Plan for the Missed AlertNotifications get missed; that’s not a failure to engineer away, it’s a reality to design around. Making the last line of defense a phone call that escalates up the hierarchy, rather than one more message, is what turns a monitoring system into one you can actually sleep behind.

As we look ahead, we’re pushing Sentinel from detecting problems toward diagnosing them: AI-generated incident summaries that propose a probable root cause, and automatic linking of alerts to the deploys that likely caused them. The goal we set on day one hasn’t changed: no one at Chinmay Finlease should ever learn about a problem from a customer.

---

Chinmay Finlease Limited is an RBI-registered NBFC building instant, digital-first lending experiences. If solving problems like these sounds like your kind of work, we’d love to hear from you.