Ongoing support needs a responsibility map and a tested operating path. This fictional API example shows how to connect user-facing signals, escalation, production changes and handover evidence. It does not establish an ARCO response-time promise or a customer reliability result.
Practical artifact
EKS and GKE cost versus reliability checklistRead the HTML instructions and download the blank CSV without registration.
Define the service and coverage before the alert
Identify the user journey, application owner, platform owner, incident coordinator, business escalation contact and authorized change approver. Specify the contracted coverage hours and what happens outside them. Confirm that an alert can reach a staffed route rather than assuming a dashboard creates operational coverage.
A fictional public API might measure successful valid requests and latency over a defined window. Agree exclusions explicitly: counting health checks as user traffic or silently removing maintenance can distort the result. Keep definitions consistent with the business service rather than selecting whichever metric is easiest to make green.
Worked error-budget arithmetic
For an illustrative 99.9% request-success objective, the allowed bad-request fraction is 0.1%. If a selected window has a 0.5% bad-request fraction, its burn rate is 0.5 divided by 0.1, or five times budget consumption. This is sample arithmetic, not an appropriate objective for every workload.
Google SRE describes multiwindow, multi-burn-rate alerting. Choose windows and notification routes based on the service, traffic and response capacity. A single five-times observation is not a complete paging rule. Validate behavior against historical incidents and low-traffic periods before enabling notifications.
allowed_bad_fraction = 1 - 0.999 # 0.001
observed_bad_fraction = 0.005
burn_rate = observed_bad_fraction / allowed_bad_fraction # 5Test the full operating path
Run an approved exercise using synthetic traffic or a controlled non-production fault. Confirm that the alert identifies the affected service, reaches the agreed recipient and links to a current runbook. Record acknowledgement, investigation, change authorization, rollback and customer communications as separate responsibilities.
For EKS or GKE, include deployment health, pending workloads, disruption constraints and recovery dependencies. Do not validate only a happy-path deployment. Confirm how DNS, data stores, third-party integrations and access failures affect recovery. Agree who can authorize a restore or a data-loss tradeoff.
Accept the handover with an evidence bundle
The receiving engineer should use the runbook to identify the symptom, inspect the agreed dashboard and perform an authorized recovery exercise. Capture the tested revision, result, unresolved exceptions, owners and next review date. A document being delivered is not evidence that another engineer can operate the service.
Support hours, severity definitions, escalation contacts, response targets and exclusions are agreed with each client on mutual terms. Review the operating plan with the delivery lead and the customer operating owner before using it as a contractual runbook. Link it to the actual project acceptance record, not an invented universal SLA.
Before acting, confirm the owner, evidence, production risk, expected outcome, and validation method for each recommendation.