Hire an AI site reliability engineer

Everything it can hand back

Your task sets the actual outputs. The specialist picks the methods that cover them.

• Reliability targets for the service, each with how to measure it
• An error budget and the rule for what to do when it runs out
• Alert rules tied to how fast the budget burns, with who is paged
• A list of manual jobs to automate, ranked
• Recovery checks to test before you need them

How it does the job well

• Every target is "proposed" unless the user gave data for it. Never invent traffic, error rates or past uptime. When there are no numbers, say what to measure first and give a starting target to confirm.
• Never write that a service "is reliable" or "meets its target". You have no measurements unless the user pasted them.
• Alert rule thresholds and windows from the profile are examples. Show your working or label them "starting point, tune against your data".
• Do not change alerts, deploy, restart anything or run a failure test. Prepare drafts and ask first.
• If this is a live outage, say so, point to the Incident Response Commander agent, and stop. Do not write a plan mid-incident.
• SLOs drive decisions — If there's error budget remaining, ship features. If not, fix reliability.
• Measure before optimizing — No reliability work without data showing the problem

Mistakes it avoids

• Setting a target because it sounds good, with no link to what users feel.
• Alerting on every spike. If nobody can act on it, leave it out.
• Blaming a person for a failure. Fix the system.
• Copying the profile's sample targets as the user's facts.
• Claiming code works without running it or its tests.
• Inventing APIs, package versions or settings instead of checking the installed ones.

What a good result looks like

An example, not your task: Customers have started to notice your site or app going down, and you have no written goal for how reliable it should be.

• Service scope. The service, its users and what they would call broken.
• Reliability targets. Each measure with a target, a time window and how to measure it.
• Error budget. How much failure each target allows, and what to do when it runs out.
• Alert rules. Fast and slow burn alerts with who is paged and what to check first.
• What you can see. Delay, traffic, errors and load, marked seen or blind spot.
• Recovery checks. Checks to test before you need them, with an owner and how often.

How the work is checked

• The changed files build, and the relevant tests and linters pass. The commands and results are shown.
• Each change is explained in one line with its reason, and risky areas are named.
• Any check that could not run is reported as NOT_RUN with what it needs.
• States which checks passed, failed or could not run, and names missing inputs.

These checks have not been run against a model yet. Your AI uses them to check its own work.

Capabilities

• Fix the scope. It picks the one service and what users do on it. Anything missing is asked once, then marked MISSING.
• Define "working". It turns user pain into measures, such as the share of requests that succeed and the share that finish fast enough.
• Set targets and a budget. It proposes a target and a time window for each measure, then works out how much failure the target allows.
• Draft the alerts. It writes a fast alert for sudden burn and a slow alert for steady burn. It says who is paged and who is only told.
• Check what you can see. It checks you can watch delay, traffic, errors and load, and lists any blind spots.
• Plan recovery and cut repeat work. It lists recovery checks to test and the repeat manual jobs worth automating.

How the role works

1. Checks your task, context and available tools.
2. Picks the methods needed and prepares a work plan.
3. Carries out supported tasks, with each method's limits and review gates.
4. Checks the real deliverables and corrects supported faults.
5. Hands back files, evidence and unresolved gaps.

Your specialist's working setup

Download the base specialist without a task form or account. README.md and SETUP.md explain how to use the folder. SOUL.md defines its scope. INTAKE.md asks missing questions inside your AI. PLAYBOOK.md, SKILLS.md, BEST_PRACTICES.md, CHECKS.md and HANDOFF.md guide the work and its checked deliverables.

Complete associated skills, supporting files and licences are included. Choose only the methods needed for the actual task. Keep context, working files and accepted feedback in your AI project.

Use this specialist through MCP or the API

Call prepare_specialist with role_id engineering-sre only. No task is required to load it. Your AI asks what job you need done, what you want back and which relevant context it can use.

For task-led hiring, call find_specialist, explain the suggested specialists and let the user accept or change the team.

Complete ZIP: Download base specialist. API: GET /api/v1/specialists/engineering-sre/pack. The host AI supplies its own model, tools and execution; a pack does not connect accounts or run a task.

Inputs and helpful context

The specialist starts from the task brief. Only active methods require their inputs.

For the primary method, when used

• The service name and what users do with it, such as logging in, paying or loading a page
• How it runs, in a few lines. Name the host or cloud, the main parts and how you release changes.
• What your users would call broken, and the worst failures you have had
• Your current monitoring, alerts and who gets paged (optional)
• Request and error numbers for the last 30 days (optional)

Helpful context (optional)

• A screenshot or export of request and error rates for 30 days.
• Your last two outage write-ups, if you have them.
• Your current alert list.

Tools and access

• Claude, ChatGPT or Gemini with file upload: It can read an exported chart, an alert list or an old outage write-up next to your description.

Functions and deliverables

• Site reliability engineer: Turn how your service fails into reliability goals, alert rules and recovery checks. Give it your service details and get a plan to review.
  • Reliability targets for the service, each with how to measure it
  • An error budget and the rule for what to do when it runs out
  • Alert rules tied to how fast the budget burns, with who is paged
  • A list of manual jobs to automate, ranked
  • Recovery checks to test before you need them
  Source: Michael Sitarzewski and Agency Agents contributors.
• Service reliability target planner: Use service goals and data to set targets, allowed failure shares, and draft alert rules.
  • Two or three measures of what users feel, with the queries to read them
  • A target and time window for each
  • An error budget in minutes or in failed requests
  • A rule for what to do as the budget runs down
  • Alert rules for fast and slow budget burn
  Source: sickn33.
• Uptime and alert setup planner: Share your system, service goals and on-call owners. Get a monitoring and alert plan to configure and verify.
  • A list of checks across the four layers
  • Targets and an error budget
  • Alert rules split into page and quiet channel
  • An on-call rotation plan
  Source: RampStack.
• Service error budget planner: Describe your service. Get targets from measured results, error budgets and alert rules.
  • A chosen indicator and target
  • An error budget calculation
  • Burn-rate alert thresholds
  • An error budget policy
  • A review of common target mistakes
  Source: Alireza Rezvani.
• AI project context organiser: Share your project and next task. Get a short rules file, a focused file list and a clear handoff for later sessions.
  • A ready rules file for your project
  • A list of which files to load for each task
  • Rules for when to reset or trim the session
  • A checklist for spotting drifting answers
  Source: Addy Osmani.

Tasks you can use it for

• Customers have started to notice your site or app going down, and you have no written goal for how reliable it should be.
• Your alerts fire all night and the team now ignores them.
• You want to decide when to pause new features and fix stability, and need a rule that is not a gut call.
• A big launch is coming and you want to know what could fail and how you would recover.

Limits to check before starting

• Your service is down right now. Use the Incident response coordinator.
• You want only targets and an error budget for one service. Use the Service reliability target planner.
• You run a small site and want simple uptime pings and an on-call plan. Use the Uptime and alert setup planner.

Best way to use this role

Give it one clear outcome, the actual files and a definition of done. Keep the work in one AI project so it can reuse checked context and earlier files.

• Download the pack from this page and add it to your AI as a skill. If you cannot, paste SKILL.md into a new chat, then paste references/source-agent.md.
• Describe one service in plain words. Say what users do on it, how it runs and how it has failed before.
• Paste any numbers you have, such as request counts and error rates from your monitoring tool. If you have none, say so. It will mark targets as proposals. No code running or web access is needed.
• Type "Make the reliability plan. Mark any number you did not give me as proposed."
• Check the targets first. Ask yourself if a user would really call a miss "broken". Fix any that are wrong and ask it to run again.
• Take the alert rules and recovery checks to the person who runs your monitoring. The AI cannot change alerts for you.

Read it as data

Read the complete role setup as JSON. Connect your AI to the AI Blocks MCP library and read aiblocks://roles/engineering-sre for its role instructions and pinned sources.

This is a prepared AI role. No task has run. Your AI carries out authorized work using its available tools and reports the actual deliverables and checks.