Observability & SRE: The Key to Reliable Business Apps in 2026

In the early hours of February 14, 2026, the checkout system of Belanjaku.id — a fashion e-commerce platform processing more than 80,000 transactions a month — stopped responding after a routine deployment at 1:40 AM broke its connection to a third-party payment gateway. No alert fired, because the engineering team relied entirely on manual reports from customer service. The outage wasn't discovered until 7:15 AM, when the marketing team checked the morning sales dashboard and found zero transactions recorded for more than five hours straight.

During that window, Belanjaku.id lost an estimated Rp 340 million in potential revenue based on average morning peak-hour sales, while 2,100 users attempting to check out received a generic error message with no explanation. Complaints flooded their official Instagram comments, and the hashtag #BelanjakuError briefly trended on X. The engineering team only identified the root cause — an expired API certificate on the payment gateway — after two hours of manually combing through server logs one at a time, with no centralized tooling to speed the search.

Cases like this are becoming increasingly common among fast-growing Indonesian businesses that have digitized aggressively without ever investing in the ability to watch their own systems' health. E-commerce, fintech, logistics, and manufacturing companies running internal ERP systems now all depend on applications that must stay up around the clock — yet many of them still find out something is wrong only when a customer complains first, not when their own systems tell them.

What observability and SRE actually mean

Observability is the ability to understand a system's internal state purely by examining the outputs it produces, and in practice it rests on three pillars: logs (detailed records of events happening inside each component), metrics (measurable numbers over time, such as latency, error rate, and resource usage), and traces (the path a single request takes as it crosses multiple services, especially critical in microservices architectures). The three complement each other — metrics tell you something is wrong, logs explain the details, and traces pinpoint exactly where in the request flow the problem occurred.

Site Reliability Engineering (SRE) is the discipline of applying software engineering approaches to operational problems, built around two core concepts: SLOs (Service Level Objectives) — measurable reliability targets, such as "99.9% of requests succeed within 300ms" — and error budgets, the amount of allowed failure before that SLO is breached. Once the error budget runs out, the team is expected to prioritize stability work over shipping new features. In practice, SRE isn't just a job title — it's a working culture that measures reliability objectively instead of relying on gut feeling or angry customer reports.

The real cost of running a business application without observability

• Slow incident detection because you rely on customer reports. Without automated monitoring, the first way a business learns something is broken is through social media complaints or support tickets — by which point reputational damage is already done and revenue losses have been accumulating for hours.
• No root-cause data when incidents happen. When a system goes down, teams are forced to manually trawl through logs across multiple servers with no centralized search, stretching resolution time from minutes into hours while increasing the risk of mistakes made under pressure.
• The same incidents keep recurring. Without a postmortem process and long-term metric trend tracking, underlying causes often never get properly fixed — teams patch symptoms temporarily, and similar problems resurface within weeks.
• Customer churn with no traceable source. Users who hit errors at checkout or experience slow load times frequently switch to a competitor without ever saying why, and the business never learns how much revenue silently walked out the door because of an undetected bad experience.
• Engineering burnout from constant firefighting. Without proactive visibility, technical teams live in permanent reactive mode — woken at midnight by an angry customer rather than a well-targeted alert — which accelerates turnover among the best engineers on the team.

The key components every observability system needs

• Centralized logging. All logs from every service, server, and container are collected in one searchable, filterable place, replacing the habit of SSH-ing into servers one by one during an incident.
• Real-time metrics and dashboards. Visualization of key numbers — response time, throughput, error rate, CPU and memory usage — in one view that both operations teams and business leadership can check at any time.
• Distributed tracing. For systems with many interconnected services, tracing lets teams see exactly which service is slowing down or failing a request, instead of guessing across dozens of components.
• Uptime and synthetic monitoring. Automated checks from outside the system — simulating real user behavior like logging in or completing a checkout — running every few minutes to confirm the application is genuinely reachable by the public, not just that "the server is on."
• Alerting with a clear on-call rotation. Automatic notifications routed to the right channel (Slack, WhatsApp, phone call) with escalation rules and a defined schedule of who is responsible for handling incidents outside business hours, so nothing falls through the cracks because "it wasn't my shift."
• SLO and error budget tracking. Reliability targets agreed on with the business side, monitored automatically, and used as an objective basis for deciding when to prioritize stability over new features.
• A post-incident postmortem process. Every significant outage is documented in a blameless way, recording the timeline, root cause, and concrete preventive actions so the same incident doesn't happen twice.

Build in-house or use an observability SaaS platform

A self-hosted approach using an open-source stack — Prometheus for metrics, Grafana for dashboards, Loki or the ELK stack for logging — offers full control over data and lower licensing costs over the long run, and works especially well for businesses with high data volumes and a technical team mature enough to manage this additional layer of infrastructure. The trade-off is a significant upfront setup investment and ongoing maintenance responsibility, including scaling ever-growing log storage, which for many small-to-medium Indonesian businesses becomes a new operational burden layered on top of an already complex core system.

SaaS platforms such as Datadog, New Relic, or regional alternatives offer faster time-to-value because most integrations already exist as ready-made plugins, with a predictable subscription model based on data volume. The trade-off is a monthly bill that can grow significantly as traffic scales, plus the fact that operational business data now lives on third-party infrastructure — a meaningful consideration for fintech companies or ERPs operating under strict data regulations. Many Indonesian businesses ultimately land on a hybrid approach: an open-source observability stack integrated directly into their custom system's architecture, combined with an external uptime monitoring service that checks availability independently from outside their internal network — a combination that delivers full control alongside an objective, independent verification layer.

Typical cost and implementation timelines in Indonesia

For a mid-size business application with a monolithic or lightly distributed architecture, implementing baseline observability — centralized logging, metrics dashboards, uptime monitoring, and on-call alerting — typically costs between Rp 50 million and Rp 140 million, with a delivery timeline of 3 to 6 weeks depending on the complexity of the existing system. For microservices-based platforms with dozens of interconnected services, where distributed tracing becomes a genuine requirement rather than a nice-to-have, the cost range climbs to Rp 180 million to Rp 400 million with an implementation timeline of 2 to 4 months, covering code instrumentation across every service, per-team dashboard configuration, and training staff on the new on-call process.

Ongoing monthly operating costs after implementation vary depending on the architecture chosen: a self-hosted setup generally runs Rp 3 million to Rp 15 million per month in additional server infrastructure, while a full SaaS setup can reach Rp 10 million to Rp 50 million per month depending on data volume processed — and frequently becomes a steadily growing line item if it isn't managed with a proper data retention strategy from day one.

Case study: Kirimcepat Logistics

Kirimcepat Logistics, a last-mile delivery provider running a tracking app and dispatch system for more than 400 partner couriers, experienced an average of three significant downtime incidents per month throughout 2025, with a mean-time-to-detect (MTTD) of 95 minutes because they relied solely on courier and call-center complaints to learn something was wrong. After implementing an integrated observability system in early 2026 — covering per-region uptime monitoring, distributed tracing for their dispatch API, and a formal on-call rotation for the engineering team — their MTTD dropped to an average of 4 minutes, while mean-time-to-resolve (MTTR) fell from an average of 3 hours to just 28 minutes.

In the first three months after implementation, customer-facing incidents dropped by 68%, largely because the team could now catch and fix anomalies before they escalated into a full outage, thanks to threshold-based alerting on error rates. Their tracking service's uptime rose from 98.2% to 99.7% within the same quarter, and customer complaints about "delivery status not updating" fell by more than half according to their internal support ticket data.

Metrics worth tracking

• Mean Time to Detect (MTTD) — how long it takes from the moment a problem occurs until the team notices, ideally measured in minutes, not hours.
• Mean Time to Resolve (MTTR) — the total time from detection to full resolution, when service genuinely returns to normal for users.
• Uptime percentage — the percentage of time the system is accessible and functioning normally, typically targeted between 99.5% and 99.99% depending on how critical the service is.
• Error budget burn rate — how quickly the remaining failure allowance is being consumed relative to the SLO target, an early warning signal before the SLO is actually breached.
• Request latency (p95/p99) — response time at the 95th and 99th percentile, revealing the worst experiences that a healthy-looking average often hides.

Implementation challenges and how to solve them

One of the most common challenges is alert fatigue, where a team receives so many notifications — including insignificant ones — that they eventually start ignoring all of them, critical alerts included. The fix is designing tiered alert thresholds from the very start of implementation, separating signals that require immediate action (paging) from purely informational signals that belong on a dashboard without waking anyone up, and regularly reviewing and adjusting those thresholds based on real historical incident data rather than assumptions made on paper.

A second challenge is the steadily growing cost of storing observability data, particularly high-volume logs and traces that, without a clear strategy, can inflate infrastructure or SaaS bills significantly within a matter of months. An effective approach is a tiered retention policy — keeping raw data at full fidelity for only the last 7 to 14 days for active debugging needs, while older data gets aggregated into long-term metric summaries for trend analysis, keeping storage costs under control without losing important historical visibility.

The third challenge, and often the hardest to overcome, is cultural resistance to on-call responsibilities — many engineering teams in Indonesia aren't yet used to being on standby outside business hours and view it as an added burden without clear compensation. Overcoming this requires commitment from management: transparent on-call compensation, fair rotation schedules that don't overload one or two people, and a blameless postmortem culture that treats incidents as opportunities to learn about the system rather than a hunt for someone to blame — an approach that ultimately improves retention of top technical talent because they feel supported, not sacrificed, when something breaks.

Where to start

Observability is no longer a luxury reserved for large tech companies — for any business whose revenue now depends on an application, e-commerce platform, or ERP system running around the clock, the ability to detect problems in minutes rather than waiting for customer complaints is an investment that pays for itself the first time it prevents an incident. AFSS helps businesses design and implement observability systems built directly into the architecture of an existing application, ERP, or platform, scaled to fit each company's size and budget. Check pricing for an idea of the investment involved, or go ahead and submit your project to discuss your system's specific needs.