SLOs and error budgets for startups: start with one customer journey

Choose an outcome customers recognize

CPU utilization is useful diagnostic information, but customers care whether they can sign in, submit an order or finish an import. Pick one journey with clear business importance and a reliable way to observe success. For asynchronous work, measure completion within an expected interval rather than only the request that accepted the job.

Write the scope in plain language. For example: eligible document-processing jobs should complete successfully within the agreed time window. Then define eligibility, success and the point at which the clock starts and stops. That prevents different dashboards from silently measuring different services.

Reference: source 1

Define the measurement before the target

Record the count of good events and the count of eligible events. Choose a window suitable for the business and enough traffic to interpret the result. Document exclusions such as deliberately rejected invalid requests, and avoid excluding failures merely because they originate in a dependency.

For low-volume services, a short window may produce unstable percentages. Combine event-based measurement with synthetic checks and review individual failures. Missing telemetry should be visible; it should not silently improve the apparent success rate.

Calculate an error budget with clear units

For an event-based target of 99.5% over 20,000 eligible events, the budget is 0.5% of those events: 100 unsuccessful events. This is an illustrative calculation, not a recommended target. A time-based availability target uses time units instead and should not be mixed with request counts.

Latency objectives need equally clear classification. If a successful response arrives too late for the defined journey, it can count as bad for that latency objective. Track different objectives separately when they answer different questions, such as availability and timely completion.

Agree what happens when the budget burns

An error budget is useful when it changes decisions. Define how the team responds to rapid consumption, a nearly exhausted budget and a completed window that misses the target. Actions might include investigating the regression, limiting rollout or prioritizing a reliability fix.

Keep the policy proportionate. An automatic freeze without context can block a needed recovery release. Give an accountable owner a documented route for exceptions. Alerts should indicate urgency and lead to an action rather than simply announce that a graph crossed a line.

Run the first objective as an operating experiment

Instrument the journey, collect a baseline and review whether the target reflects actual customer needs. Look at the failures behind the percentage. A small number of repeated failures for one tenant can be hidden by a healthy aggregate, so inspect useful segments without creating excessive metric cardinality.

Review the objective after incidents and material product changes. Keep its definition, owner and response policy accessible to the people releasing software. Latifold's operational context is designed to help agents investigate supported infrastructure and recent changes. It does not establish your application's SLOs or run its error-budget process. Keep the objective tied to customer outcomes, with a named response owner and evidence your team can inspect.