Devops Engineer Onboarding Checklist
Everything you need to onboard a devops engineer from Day 1 through their first 90 days. Customizable for your company size and work setup.
Last updated May 21, 2026 • By Pro Sulum • Free to use, no signup
Get My Free Devops Engineer Onboarding ChecklistSample Devops Engineer Onboarding Checklist
Day 1: Complete administrative setup and provision all communication and initial read-only system access without exposing production write permissions.
- Complete new hire paperwork and benefits enrollment — Process I-9, W-4, direct deposit, and benefits selections. Sign NDA and IP agreement given the sensitive nature of infrastructure access. critical
- Set up email, Slack, and company GitHub/GitLab organization access — Configure corporate email, add to all relevant Slack channels (engineering, incidents, deployments, on-call), and add to the GitHub or GitLab org with read access to core repositories. critical
- Provision read-only AWS or GCP console access — Create an IAM user or service account with a read-only policy. Write and deployment permissions are added after the infrastructure walkthrough in week one. critical
- Set up VPN access and configure MFA on all accounts — Configure the company VPN, enforce multi-factor authentication on cloud console, GitHub, and all tooling, and confirm the new engineer can connect to internal environments. critical
- Meet the engineering lead and receive a high-level architecture overview — One-hour session with the engineering lead or CTO covering the technology stack, deployment philosophy, and the DevOps engineer's initial scope and priorities. critical
- Access monitoring and alerting platform (Datadog, Grafana, or PagerDuty) — Create a login to the observability stack and confirm the engineer can view dashboards, active alerts, and recent incident history. critical
- Review and acknowledge the security and access control policy — Read through the company's security policy covering credential management, access logging, change control procedures, and incident reporting obligations. critical
- Introduction to the on-call buddy and engineering team — Brief introductions to the current on-call engineer, senior DevOps engineers, and the development team leads who deploy through the pipelines. important
Week 1: Build a complete mental model of the infrastructure, CI/CD pipelines, and incident response process before any production write access is granted.
- Complete a guided CI/CD pipeline walkthrough — Walk through the full build, test, and deployment pipeline with a senior engineer covering triggers, stages, environment promotion rules, and how to roll back a failed deployment. critical
- Review the infrastructure-as-code repository (Terraform, Pulumi, or CDK) — Read through the IaC codebase to understand how environments are provisioned, naming conventions, module structure, and how infrastructure changes are reviewed and applied. critical
- Read the full incident response runbook — Work through every section of the runbook covering alerting thresholds, escalation paths, communication templates, and post-incident review procedures. critical
- Review the last 3 post-mortem reports — Read through recent post-mortems to understand what kinds of incidents have occurred, how they were handled, and what improvements were made afterward. critical
- Gain access to the secrets management system (Vault or AWS Secrets Manager) — Provision access to the secrets manager with the correct policy scope and confirm the engineer understands how secrets are rotated and audited. critical
- Walk through the Kubernetes or ECS cluster configuration — Get a hands-on tour of the container orchestration setup covering cluster structure, namespace organization, resource limits, autoscaling policies, and how deployments are tracked. important
- Receive full cloud console write access after infrastructure walkthrough — Upgrade IAM permissions from read-only to appropriate write access after the engineer has completed the infrastructure overview and demonstrated understanding of the environment. critical
- Shadow the on-call engineer for the full week — Observe all alerts, incidents, and routine operational tasks. Ask questions after each event. Do not take independent action without confirmation from the on-call buddy. critical
- Review the network topology and service dependency map — Study the architecture diagram covering VPCs, subnets, load balancers, service mesh (if applicable), and external dependencies including third-party APIs and data stores. important
Month 1: Make the first independent infrastructure contribution, complete a supervised on-call rotation, and identify at least one pipeline or reliability improvement.
- Complete first infrastructure pull request through code review — Submit an IaC change, pipeline improvement, or configuration fix as a pull request. Require approval from at least one senior engineer before merging. critical
- Complete a supervised on-call rotation — Take a full on-call shift with a senior engineer available as backup. Handle all real alerts independently but escalate decisions above a defined risk threshold. critical
- Complete a tabletop incident response exercise — Participate in a simulated incident scenario with the team to practice following the runbook, communicating status, and coordinating resolution steps. important
- Document one undocumented infrastructure component or process — Identify a system or procedure that exists in practice but lacks documentation and write a clear, accurate description for the team wiki. important
- Set up personal alerting and notification preferences in PagerDuty or OpsGenie — Configure alert routing, escalation policies, and notification channels so the engineer receives the right alerts at the right severity threshold. critical
- One-on-one meetings with each development team lead — Meet with the leads for each team that uses the CI/CD pipeline to understand their deployment needs, pain points, and current friction in the release process. important
- Present a list of 3 infrastructure or reliability improvements to the team — Based on the first month of observation, propose three specific improvements to reliability, deployment speed, or operational toil reduction with rough effort estimates. important
- Review cost allocation reports in AWS Cost Explorer or GCP Billing — Understand how cloud spend is tracked, where the largest cost drivers are, and what cost optimization initiatives are already in flight. nice-to-have
90 Days: Operate as a fully independent member of the DevOps team, owning at least one pipeline improvement and capable of handling on-call independently.
- Ship a meaningful pipeline or infrastructure improvement — Deliver a completed improvement from the list proposed at month one, such as a faster build pipeline, improved test parallelization, or an automated rollback mechanism. critical
- Complete 90-day performance review with engineering lead — Review progress against agreed goals, discuss areas for growth, and set technical focus areas for the next quarter. critical
- Take independent on-call rotation without a backup shadow — Handle a full on-call week independently, using the runbook and escalation paths as intended. Review performance with the team afterward. critical
- Write or update a section of the incident response runbook — Based on direct experience handling incidents, update or add a runbook section to reflect what you learned, what was missing, and what would have been helpful. important
- Lead a brief infrastructure knowledge-sharing session with the engineering team — Present a 20-30 minute walkthrough of one infrastructure system or a recent improvement to help developers understand how their deployments work. nice-to-have
- Identify and propose one cost reduction or efficiency improvement — Use cloud billing reports and usage data to identify a specific opportunity to reduce waste or right-size resources, with a projected savings estimate. important
- Complete a security review of IAM roles and permissions in the cloud environment — Audit current IAM policies for over-permissioned roles, unused service accounts, and any access configurations that deviate from least-privilege principles. important
- Establish a recurring 1-on-1 cadence with the engineering lead — Set a standing weekly or biweekly 1-on-1 to discuss infrastructure priorities, blockers, and professional development goals going forward. important
Small business owners hiring a Devops Engineer for the first time face a tough situation. Without an HR team or prior experience onboarding this specific role, it can feel overwhelming. Time is tight, and there is no ready-made playbook for how to bring someone into a technical position that touches both development and operations. Owners often worry about missing critical steps or slowing down the new hire's progress, especially since they are juggling many other responsibilities. This uncertainty can cause delays or frustration right at the start. During the first week, the most important priority for a Devops Engineer in a small business is to get access to the core systems and understand how the current infrastructure works. Unlike larger companies with complex layers, small businesses often have simpler setups but less documentation. The new hire needs to connect with servers, tools, cloud accounts, deployment pipelines, and monitoring systems quickly. This foundational understanding allows them to spot immediate issues and start improving stability or automation. Without this, the engineer is stuck waiting and observing instead of adding value. One practical approach to training without spending hours in meetings or feeling like you have to micromanage is the "Record & Delegate" method. Before the new hire starts, record a short video showing yourself completing the top 3 to 5 critical tasks the Devops Engineer will handle. This could include pushing a code update, restarting a service, or checking logs for errors. The video acts as a step-by-step guide and becomes the standard operating procedure for those tasks. When the new engineer watches it, they get clear instructions and can try it themselves. This method reduces back-and-forth questions and helps the owner avoid becoming a bottleneck. The single most common onboarding mistake is expecting the Devops Engineer to immediately fix every problem without giving them time to understand existing tools and workflows. Small business owners often want quick fixes but don’t provide enough context or access upfront. This leads to frustration on both sides and slows down progress. It is better to focus on building a foundation during the first few weeks than pushing for major changes too soon. At 90 days, a Devops Engineer who is ready to work independently in a small business will have full access to and understanding of the infrastructure. They will be able to deploy updates, troubleshoot incidents, and improve automation without needing constant guidance. They will have documented processes for common tasks and started to suggest improvements that fit the company’s scale and budget. This shows they have moved from learning mode into ownership and can handle daily operations and project work confidently. If you want a DevOps Engineer who documents their own processes and builds systems as they go, rather than requiring you to document everything first, that is what a Virtual Systems Architect does. Start with this checklist.
Frequently Asked Questions
I hired someone for this role before and it did not work out. What usually goes wrong?
Most failed DevOps Engineer hires come down to one of three problems: the owner skipped structured onboarding in week one, there was no documented process for the hire to follow, or expectations were never made explicit. The new hire guessed, made mistakes, and the owner assumed the person was the problem. In most cases the process was the problem. This checklist closes all three gaps. Start with a clear first week, a Record and Delegate video for each core task, and written expectations before the hire ever logs in.
What skills should I look for when hiring a Devops Engineer for a small business?
Look for experience with cloud platforms you use, automation tools, scripting, and familiarity with both development and operations tasks. Communication skills and the ability to work independently are also key.
How do I know if a candidate is a good fit without a technical background?
Ask for examples of past projects and how they solved problems. Consider having a trusted technical advisor help with interviews or use simple practical tests to gauge skills.
What access should I provide to the new Devops Engineer initially?
Give access to key infrastructure like servers, cloud accounts, deployment tools, and monitoring dashboards. Make sure credentials are secure but available so they can start working immediately.
How can I avoid overwhelming the new hire in their first week?
Focus on the most critical systems and tasks first. Use the "Record & Delegate" method to show them how things work. Avoid asking them to fix everything at once.
How much time should I expect to spend onboarding a Devops Engineer?
Plan for some upfront time to create training materials and provide access. After that, regular check-ins for the first few weeks usually suffice as they become more independent.
What signs show the Devops Engineer is ready to work independently?
They confidently handle deployments, troubleshoot issues, and suggest improvements without needing constant help. They also document processes and communicate clearly about system status.
Related Onboarding Checklists
Read Next
Go beyond the checklist
What if someone else ran this onboarding process for you?
Pro Sulum's Virtual Systems Architects document your processes and run new-hire training from Day 1 through Day 90, so you never have to.
97% stay past year one.
Schedule a Free 30-Minute Discovery Call