SRE consulting for growing teams: SLOs, error budgets and the first 90 days

Choose a narrow reliability scope

Start with a service whose failures affect customers or revenue. Define the successful event from the user's perspective, such as completed checkout or accepted API request. Infrastructure health can support that indicator, but it is not the user outcome.

Confirm who owns the service, who can change it and which dependencies sit outside the team.

Define an SLI and a realistic SLO

A service-level indicator is the measured behaviour, such as the proportion of valid requests completed within a threshold. The service-level objective is the target over a defined window.

Use current telemetry to understand normal performance before setting the target. An arbitrary 99.99% promise can create cost without improving the customer experience.

A practical first 90 days

The first month establishes scope, telemetry gaps and incident patterns. The second implements dashboards, alerts and runbooks around the selected journey. The third tests the operating model during releases and incidents.

• Days 1-30: service map, baseline and candidate SLO
• Days 31-60: instrumentation, alerting and ownership
• Days 61-90: error-budget policy, game day and backlog

What an SRE consultant should not promise

A consultant cannot guarantee zero incidents. They can define reliability targets, test response paths and reduce specific sources of toil and failure.

If the engagement includes on-call or production response, coverage hours, escalation, access and exclusions must be explicit. DevOpsConsulting.ie does not advertise a 24/7 managed operations service.

Design an SLI that represents the customer experience

Start with the event that should succeed: an API request, checkout, search, file processing job or another critical journey. Define valid events, successful events and the observation point. Measuring at the edge may include failures hidden from an application metric; measuring inside the service may provide better diagnosis but miss network or dependency impact.

Document exclusions carefully. Planned maintenance, test traffic or client errors may be treated differently, but broad exclusions can make the number look healthy while customers fail. Check data completeness and delay, especially when an SLO will influence release decisions. The query and dashboard should be version controlled or otherwise reviewed.

Choose an objective from business tolerance and observed performance, not from the number of nines that sounds professional. A tighter objective consumes engineering capacity and may require different architecture. Record the review period, calculation, owner and what decision the objective is intended to support.

• User journey and measurement boundary
• Valid-event and successful-event definitions
• Data source, freshness and known gaps
• Objective, review window and business rationale
• Owner and action when reliability falls outside policy

Create a reliability operating cadence

A dashboard alone does not create SRE practice. Review the selected service on a regular cadence with product and engineering owners. Examine SLO trend, incidents, alert quality, risky changes, recurring toil and the status of reliability work. Keep the meeting focused on decisions rather than presenting every metric collected.

Use incident learning to improve the system and the response. Actions should name an owner and connect to a failure mode; “add monitoring” is not complete until a signal, threshold, response and test are defined. Review old actions and close those that no longer address meaningful risk.

Toil should be recorded where it enters the team: manual releases, repeated restarts, access requests, capacity adjustments or data repair. Automate or remove the highest recurring work when the expected saved effort and reliability benefit justify the change.

Frequently asked questions