An internal application can be technically available and still fail the people who depend on it. A request may return an error, a queue may take too long to clear, or a report may complete while quietly omitting records. If the team only watches whether a server is up, it may discover the problem after the business process has already stalled.
Service-level objectives (SLOs) provide a practical way to define what reliable service means. They are useful beyond large technology companies. A small business can use a few focused objectives to connect application monitoring with the workflows that matter, without building an elaborate reliability program.
Start with the terms
A service-level indicator (SLI) is a measurement of one aspect of service quality. Examples include the percentage of requests that succeed, the time it takes to return a result, or the percentage of queued jobs completed within a defined window.
A service-level objective (SLO) is the target for an SLI over a stated period. For example, an objective might say that at least 99.5% of valid order-submission requests should succeed during a calendar month. The target is meaningful because it names what counts as good service and when it will be evaluated.
A service-level agreement (SLA) is a formal agreement that may include commitments and consequences. An internal application may need SLOs without needing an SLA. Keeping those concepts separate prevents an internal target from accidentally becoming a customer-facing promise.
Choose critical workflows before choosing metrics
Do not begin with every metric your hosting platform can produce. Begin with the work people need the application to support. List the important user journeys and rank them by business impact.
A customer-service team might depend on searching an account, recording a case, and sending a follow-up. An operations team might depend on importing a file, reviewing exceptions, and exporting approved records to another system. Each journey has a different definition of failure. A healthy CPU graph cannot tell you whether the export contains all the approved records.
For each journey, write down:
- who performs it and how often;
- what a successful outcome looks like;
- how long a person can reasonably wait;
- what happens if it fails or produces incomplete data; and
- who owns the next response.
This exercise also helps keep the scope practical. If a workflow is rarely used and has a simple manual fallback, it may not need the same target as the process that controls daily fulfillment.
Define “good” service precisely
Vague objectives create dashboards that nobody trusts. Define the good and bad events in terms that the application can measure.
For availability, count successful valid requests rather than treating every HTTP request as equal. A user who sends an invalid form should not necessarily count as an application failure. For latency, define the action and the acceptable time window. “Fast” is not a useful target; “the account search returns results within two seconds for 95% of valid searches” is testable.
For background processing, measure completion and age. A job queue can be accepting new work while old jobs remain stuck. Useful indicators might include the percentage of jobs completed within 15 minutes and the age of the oldest unprocessed job.
Correctness often needs a business check rather than an infrastructure metric. If an integration reports success but drops records, request latency will look fine. Reconciliation counts, duplicate detection, and sampled review can provide signals that the workflow is producing the intended result.
Set targets from evidence
Targets should reflect the workflow’s needs and the system’s current behavior. Avoid choosing a string of 9s because it sounds professional. A target that cannot be measured or supported by the team is not a reliability plan.
Start by collecting a baseline for a representative period. Look for normal busy periods, scheduled maintenance, manual delays, and known failure modes. Then ask what level of missed service the business can absorb. A target for an internal report may allow a longer completion window than a target for a transaction that blocks a customer-facing handoff.
It can help to translate the objective into a review question: “If we miss this target, what decision should change?” If the answer is nothing, the metric may be interesting but does not need SLO status. Keep the initial set small enough that the team will review it regularly.
Make alerts actionable
An SLO is not useful if it only appears in a monthly report after the damage is done. Pair objectives with signals that help the owner act. An alert should identify the affected workflow, the observed symptom, the likely scope, and the next runbook step.
Use different thresholds for investigation and urgent response. A short spike in latency may deserve a ticket or trend review, while a sustained failure of a critical submission path may require immediate ownership. Avoid alerting on every low-level fluctuation; excessive alerts train people to ignore the channel.
Monitoring should combine application events with infrastructure data where needed. Logs can explain an error, metrics can show its frequency, and a synthetic check can confirm whether a critical path works from a user perspective. The goal is a clearer decision, not a larger pile of telemetry.
Review misses without blame
When an objective is missed, record what happened and what the team learned. Was the target unrealistic? Did an upstream dependency fail? Was the signal measuring the wrong part of the workflow? Did the response owner lack the access or documentation needed to act?
Use the answer to improve the system or the operating model. That may mean adding a queue, changing a timeout, documenting a manual fallback, adjusting a target, or testing a recovery procedure. An SLO should guide prioritization rather than become a scorecard used to punish the person who received the alert.
A practical first version
For one internal application, choose two or three critical workflows. Define one or two indicators for each, write a target and measurement window, establish a baseline, and assign an owner. Put the results on a simple dashboard and review them at a regular operational meeting.
After a few review cycles, remove metrics that do not change decisions and add signals for important gaps. This small feedback loop is usually more valuable than trying to instrument every component before the team understands what reliability means to the business.
Next step: Schedule a short consultation to identify the next useful improvement.