Running a service starts with looking at the data.
August 25, 2026 | SKYWARE INSIGHT
This is how a service outage is usually discovered. A few calls come into the customer center saying “payments aren’t going through,” an engineer logs into the server and digs through the logs, and only much later does the team confirm that “the payment module has been responding slowly for the past 30 minutes.” Simply hunting for the cause after an outage has occurred is not enough to run a service reliably. In that setup, customers find out first and the operations team finds out last.
That is why monitoring environments that collect the many kinds of data generated by a system in real time and continuously track key metrics are becoming increasingly important. In this article, we look at what to watch, how to watch it so alerts don’t become noise, and where accumulated operational data is useful beyond incident response.
01. Infrastructure metrics alone can’t tell you the state of a service
Traditional monitoring looks at infrastructure metrics such as CPU utilization, memory and disk. Even when all of those numbers look normal, the service can still be broken. Think of a payment gateway integration lagging by 10 seconds per call, errors appearing only on certain product pages, or messages that were sent but rejected by the carrier.
To understand the true state of a service, you need to analyze not only infrastructure metrics like CPU and memory but also request volume, error rates, response times and user activity data. Today this is called observability, and it brings three things together in one view: logs, metrics and traces.
Figure 1 · The three pillars of observability
- LogsLogsWhat happened. Error messages · request records · processing results
- MetricsMetricsHow much · how fast. Request volume · error rate · response time · throughput
- TracesTracesWhere it got stuck. The service path a single request took and the time spent at each step
Logs+Metrics+Traces=Pinpoint right away whether slow payments come from the payment service or the card issuer integration behind it
02. What to watch · Four key metrics
Collecting more metrics does not automatically give you better visibility. If you narrow each service down to about four key metrics, its status can be read from a single dashboard screen. The usual baseline is latency, traffic, errors and saturation, plus one or two business metrics specific to that service.
Figure 2 · Examples of key metrics by service
| Metric | Commerce platform (SCOS) | Unified messaging (sOMP) | Why it matters |
|---|---|---|---|
| Latency | Product lookup · payment response time | Time from submission to carrier delivery | Slowing down is the first sign of an outage |
| Traffic | Orders · page requests per minute | Messages sent per minute · share by channel | Both sudden spikes and sudden drops are warning signs |
| Errors | Payment failure rate · 5xx ratio | Send failure rate · rejection codes by carrier | Watch changes in the rate, not the raw count |
| Saturation | DB connections · queue backlog | Messages waiting in the send queue · worker utilization | Tells you when to scale before you hit the limit |
| Business metrics | Cart-to-checkout conversion rate | Verification message delivery rate | Catches a stalled business even when technical metrics look normal |
The last row matters most. If the checkout conversion rate drops to half its usual level while every server metric looks normal, the problem lies outside the infrastructure, such as an external script embedded in the payment window or a misconfigured promotion. Without tracking business metrics alongside the rest, outages like this go unnoticed until the sales report comes out.
03. How to watch · Keeping alerts from becoming noise
The first problem teams run into after introducing monitoring is not outages but alert fatigue. An alert that fires every time CPU exceeds 80% gets ignored within days, and the alerts that really matter get buried in the meantime.
- Alert on symptoms, not causes Instead of “CPU at 80%,” base alerts on what customers actually experience, such as “payment response time above 2 seconds for 5 minutes.”
- Set baselines from normal patterns Send volume on a Monday morning is different from early Sunday morning. Instead of fixed thresholds, compare against typical values for the same day of the week and time of day.
- Separate by severity Distinguish between what needs to wake someone up immediately (payments down), what can wait until morning (disk at 70%), and what belongs in the weekly review (top 10 slow queries).
- Include the next action in the alert Don’t stop at “error rate rising.” Send the related dashboard link, recent deployment history and the person in charge along with it.
Recently, some teams also have AI gather logs, metrics and recent deployment history when an alert fires, then hand the engineer a summary along the lines of “this is the most likely cause.” It cuts the time spent on initial information gathering, but it is safer to leave the actual response to human judgment.
04. Where accumulated data is useful beyond incident response
Real-time monitoring is used in the following areas.
- Early outage detectionSpot changes in response times and error rates before customers pick up the phone.
- Performance degradation analysisUse trace data to narrow down which deployment and which segment caused the slowdown.
- Understanding service usageSee which features are actually used through usage broken down by time of day, channel and feature.
- Abnormal traffic detectionSecurity signals, such as repeated requests from a specific IP or abnormal login attempts, come from the same data.
- Decisions based on operational dataA record showing that only payments tripled during a promotion tells you how much to scale servers for the next event and where to invest.
As operational data accumulates, it can be used not just for incident response but also for decisions on future service expansion and infrastructure investment. With six months of send-volume trends, you no longer have to set next quarter’s capacity by gut feel, and a list of the slowest queries gives you your performance improvement priorities directly.
05. How SKYWARE runs operations
SKYWARE operates its commerce platform and unified messaging service both as on-premises deployments and as ASP services, and alongside them builds operating environments that continuously track system status and key metrics so the cause of any outage can be identified quickly. For the messaging service, we aggregate send result codes and carrier-by-carrier rejection status in real time to manage delivery quality. For the commerce platform, response times and failure rates in the order and payment flow are our key metrics.
Our principle is not to leave monitoring for later during implementation. Which metrics to watch, at what threshold to alert, and who receives the alerts are decided together at the design stage. Even when we build within a client’s internal network, we hand over the monitoring dashboards and alerting system to the same standard.
Ultimately, good operations is not only about resolving problems quickly when they occur. It starts with spotting the warning signs before a problem happens.