The bracketed "[App]" in this post's title is deliberate. This isn't a one-time write-up about a single incident — it's the recurring lens we'll point at any Nepali fintech outage as it happens, whichever app is involved. That's the point worth sitting with first: outages aren't rare, isolated accidents in this industry. They're a recurring operational reality, the same way flight delays are a recurring reality in aviation. Treating each one as a shocking anomaly misses the pattern. Treating them as a predictable category of event — with common causes, a reconstructable timeline, and measurable impact — is what actually helps merchants and users plan around them.
Why Outages Deserve a Recurring Framework, Not a One-Off Reaction
Every time a widely used wallet or banking app goes down, the same cycle repeats: social media fills with screenshots of failed transactions, rumors outpace facts, the provider posts a brief acknowledgment hours later, and within a day or two the story disappears from public attention — until the next outage, when the cycle starts again with no memory of the last one. That amnesia is the real problem. Without a consistent way to document what happened, compare it to previous incidents, and track whether providers are actually improving, every outage gets treated as a surprise rather than a data point in an ongoing pattern.
This post exists as the template for that documentation — the recurring questions we'll ask every time: what triggered it, how long between detection and acknowledgment, how providers communicated, and what it cost merchants and users in the interim. Applying the same structure each time is what turns scattered complaints into a real accountability record.
What Typically Causes Outages
Across the digital payments industry generally — not specific to any one Nepali provider — outages tend to cluster around three recurring root causes.
Server Load and Capacity Limits
Every system is built to handle a certain volume of simultaneous requests. When real traffic exceeds that provisioned capacity — whether from organic growth outpacing infrastructure upgrades, or a sudden unplanned surge — response times degrade first, then requests start timing out, and eventually the system can become unresponsive entirely. This is the most common and most preventable category, since it's a direct function of how much headroom a provider has built into their infrastructure relative to their actual user base.
Festival Traffic Spikes
Nepal's payment volume isn't evenly distributed across the year. Periods like Dashain and Tihar bring enormous, concentrated surges in transactions — gift transfers, bonus payments, retail shopping, and travel bookings all peaking simultaneously. Infrastructure that comfortably handles an average Tuesday can buckle under a festival-week Friday, particularly if capacity planning was based on average load rather than known seasonal peaks.
Bank-Side Issues
Not every outage originates with the wallet or app itself. Since most transactions ultimately route through a partner bank's core banking system and the national payment switch, a fault on either of those upstream systems can make a perfectly healthy app appear broken to its users — transactions fail or hang, even though the app's own servers are running fine. This is one of the harder categories for users to distinguish from the outside, since the visible symptom (a failed payment) looks identical regardless of which layer actually failed.
The same three triggers, the same two impact zones, the same five-stage timeline — every outage post-mortem starts from this shape.
Timeline Template: How to Reconstruct What Happened
Reconstructing an outage after the fact is part investigative habit, part discipline. Since providers rarely publish a detailed public timeline unprompted, the record has to be pieced together from a handful of consistent sources, applied the same way every time.
The Five-Stage Reconstruction Method
- Detected — Note the first verifiable sign of trouble: the earliest user complaints on social media, a spike in "is [app] down" search interest, or a status-page change, whichever comes first and is timestamped.
- Acknowledged — Record when the provider first publicly confirmed an issue was occurring, through an official social media post, in-app banner, or press statement — and how long that took after detection.
- Mitigated — Mark the point where service partially recovers — some transactions succeeding again, even if not fully stable — usually visible through a drop-off in new complaints rather than an official announcement.
- Resolved — Confirm full service restoration, ideally cross-checked against an official "services fully restored" statement rather than just the absence of new complaints.
- Post-Mortem Published — Track whether, and how long after resolution, the provider released any root-cause explanation — this stage is the one most often skipped entirely in practice, which is itself worth documenting.
Applying this same five-stage structure to every incident, rather than writing a fresh narrative each time, is what makes outages comparable to each other — how does this provider's acknowledgment gap compare to last time, is detection-to-resolution getting faster or slower over the year, and which stage does the pattern consistently break down at.
Impact on Merchants and Everyday Users During Downtime
The cost of an outage isn't evenly distributed. For an everyday user, a thirty-minute outage is usually an inconvenience — a delayed transfer, a failed top-up retried later. For a merchant relying on QR payments as a primary checkout method, the same thirty minutes can mean turning away paying customers in real time, with no immediate fallback beyond asking for cash a customer may not be carrying.
- Lost or abandoned sales at the point of checkout, particularly for merchants without a reliable card or cash backup in place.
- Ambiguous transaction states — a payment that appears to fail on the customer's screen but may have actually deducted funds, creating disputes that take days to resolve even after the outage itself ends.
- Reconciliation headaches for merchants trying to match a partial, outage-affected day's transactions against their bank statement afterward.
- Erosion of trust that compounds with each recurrence — a single outage is forgivable, but a pattern of them without visible improvement pushes both merchants and users toward keeping cash or alternative payment methods on hand as a permanent hedge.
How Providers Have Historically Communicated During Outages
Communication quality during an outage tends to fall along a predictable spectrum, and it's worth evaluating any provider — including whichever app fills the "[App]" in this post's title on a given occasion — against that spectrum rather than a vague sense of "did they say something."
| Communication Pattern | What It Looks Like | What It Signals |
|---|---|---|
| Silent | No acknowledgment; users left to guess via social media rumors | Weak incident-response process |
| Delayed, generic | A brief "we're aware of an issue" hours later, no detail | Reactive, not yet mature communication |
| Timely, specific | Prompt acknowledgment with a rough cause and ETA | Functioning incident-response team |
| Full post-mortem | Root cause, timeline, and prevention steps published after resolution | Strong accountability culture |
In practice, most incidents across the industry land somewhere between "delayed, generic" and "timely, specific," with the full post-mortem stage remaining the exception rather than the norm. That gap — between resolving an incident and actually explaining it — is usually where public trust is won or lost, since users tend to forgive downtime far more readily than they forgive silence about it.
What "Five 9s" Reliability Would Take for Nepali Fintech
"Five 9s" refers to 99.999% uptime — a standard borrowed from telecom infrastructure, where systems were expected to be so reliable that downtime became almost theoretical. It's a useful benchmark for thinking about how far current fintech reliability has to go, even if it's an aspirational rather than a currently realistic target for most providers.
| Uptime | Allowed Downtime / Year | Allowed Downtime / Month |
|---|---|---|
| 99% ("two 9s") | ~3.65 days | ~7.3 hours |
| 99.9% ("three 9s") | ~8.76 hours | ~43.8 minutes |
| 99.99% ("four 9s") | ~52.6 minutes | ~4.4 minutes |
| 99.999% ("five 9s") | ~5.26 minutes | ~26 seconds |
Closing that gap isn't one fix — it's a stack of engineering and operational investments, each expensive and each individually necessary. It requires redundant infrastructure across multiple data centers or cloud regions, so a single point of failure can't take the whole system down. It requires capacity planning built around known peak events like festivals, not average daily load. It requires automated failover systems that can reroute traffic within seconds rather than requiring a human to notice and react. And critically, it requires the same redundancy and capacity discipline from partner banks and the national payment switch, since a provider's own five-9s infrastructure is only as reliable as the weakest upstream system it depends on.
Lessons for Both Providers and Users
For Providers
- Publish a status page that updates in real time — even a simple one dramatically reduces the rumor-and-guesswork cycle during an incident.
- Acknowledge fast, even without full details — "we're aware, investigating" within minutes builds far more trust than a polished statement hours later.
- Commit to a public post-mortem as a standard practice, not a rare exception, since it's the single strongest signal that an incident is actually being learned from.
- Plan capacity around known peaks rather than average load, given how predictable Nepal's festival-driven traffic surges are.
For Merchants and Everyday Users
- Keep a fallback payment method available — cash or a card terminal — so a single provider's outage doesn't mean turning away business entirely.
- Screenshot ambiguous transactions immediately during an outage, since that's the evidence needed later if a dispute over a deducted-but-unconfirmed payment arises.
- Check official channels before assuming the worst — a provider's status page or verified social account is more reliable than a spreading rumor mid-incident.
- Track your own pattern of outages per provider over time — a single incident is normal; a repeating pattern without improvement is useful information for choosing which provider to rely on most heavily.
Discussion