--- title: "PagerDuty Engineers to Hire for Incident Response | Azendo" description: "What does PagerDuty setup take? Our PagerDuty engineers tune escalation and cut alert fatigue so on-call stays humane. A managed DevOps team from Chiang Mai." url: "https://azendo.co/skills/pagerduty/" --- 1. [Home](https://azendo.co/) 2. [Skills](https://azendo.co/skills/) 3. PagerDuty # PagerDuty specialists for your dedicated team. PagerDuty is an incident response platform handling on-call schedules, escalation policies, alert routing and deduplication, incident timelines and post-incident review data. Our PagerDuty engineers set up on-call so the right person is paged for real problems and everyone sleeps through the rest. ## When PagerDuty setup becomes real work. Adding PagerDuty to one service takes an hour. The work starts when there are forty services, six teams and alerts arriving from Datadog, Prometheus and CloudWatch at once. Somebody has to decide which alert pages whom, at what hour, and what happens when they don't answer. It becomes urgent when on-call starts to hurt. People are woken for disk warnings that clear by themselves, pages go to someone who left the team, and one outage opens thirty incidents. Those are configuration problems that can be measured and fixed. Growth brings it on as well: a first enterprise customer with an uptime clause, or the move from one on-call hero to a real rotation. ## What our PagerDuty engineers set up and maintain. * Service map Modelling technical services and the business services they support, each with an owner team and an escalation policy that always ends with a person. * Schedules Building rotations with layers, handoff times and overrides that fit how your team works across time zones. * Event routing Writing Event Orchestration rules that set severity and drop known noise, with low-urgency alerts held back until working hours. * Deduplication Setting dedup keys and alert grouping, so one failing database opens one incident. * Integrations Connecting Prometheus Alertmanager, Datadog, Grafana or CloudWatch through the Events API, with Slack and Jira on the response side. * Monthly review Reading the analytics for pages per person, time to acknowledge and the share of alerts that needed action, then cutting the noisiest rule. On-call is a people topic as much as a tooling one. The site reliability engineers we assign own PagerDuty as part of a [dedicated DevOps team](https://azendo.co/services/dedicated-cloud-and-devops-team/) that is managed by us. They work in your PagerDuty account and your monitoring tools. You talk to them directly on Slack or Teams, which helps when the subject is who gets woken at night. ## On-call mistakes PagerDuty can't fix for you. Paging on everything is the classic one. When most pages need no action, people stop reading them, and the real outage is lost in the noise. A good engineer tracks the share of pages that needed action and removes or downgrades the rest. An escalation policy with one level fails on the first missed call. Every policy needs a second person and a final fallback, and the path should be tried with a test incident. Routing by tool is harder to spot. If every Datadog alert goes to one team, that team becomes a switchboard for the others. An alert should land with the team that can fix the service. ## PagerDuty questions, answered. * What does a PagerDuty setup take? For a product with a handful of services, a first working setup is quick: services, one rotation, an escalation policy and the main integrations. Doing it well takes longer, because cutting noise needs a few weeks of real alerts to learn from. * Is PagerDuty enough without good monitoring? No. PagerDuty routes the alerts it is given, and wrong alerts get delivered very reliably. The same engineer should own the alert rules in Prometheus, Datadog or Grafana and base them on service level objectives. * Can offshore engineers in Thailand be on call for us? Yes, during hours we agree with you before the work starts. Thailand is UTC+7, so their working day runs through the night in the Americas and the early morning in Europe. ## Roles that use PagerDuty * [Site Reliability Engineer Cloud and DevOps](https://azendo.co/services/dedicated-cloud-and-devops-team/site-reliability-engineer/) ## Service areas that use PagerDuty * [Cloud and DevOps](https://azendo.co/services/dedicated-cloud-and-devops-team/) Capacity is agreed across your whole team, with one monthly fee, not per skill. ## What it's used with * [Prometheus, a skill in our teams](https://azendo.co/skills/prometheus/) * [Datadog, a skill in our teams](https://azendo.co/skills/datadog/) * [Grafana, a skill in our teams](https://azendo.co/skills/grafana/) * [CloudWatch, a skill in our teams](https://azendo.co/skills/cloudwatch/) * [New Relic, a skill in our teams](https://azendo.co/skills/new-relic/) * [SLO and error budget design, a skill in our teams](https://azendo.co/skills/slo-and-error-budget-design/) * [runbooks, a skill in our teams](https://azendo.co/skills/runbooks/) * [OpenTelemetry, a skill in our teams](https://azendo.co/skills/opentelemetry/) ## Related in observability * [Observability, a skill in our teams](https://azendo.co/skills/observability/) * [Sentry, a skill in our teams](https://azendo.co/skills/sentry/) * [Logging, a skill in our teams](https://azendo.co/skills/logging/) * [audit logging, a skill in our teams](https://azendo.co/skills/audit-logging/) * [APM, a skill in our teams](https://azendo.co/skills/apm/) * [distributed tracing, a skill in our teams](https://azendo.co/skills/distributed-tracing/) * [Database query profiling, a skill in our teams](https://azendo.co/skills/database-query-profiling/) ## Tell us what you need PagerDuty for. A service delivery manager will reply with the specialists we'd suggest, the monthly capacity and what the first month looks like. [Browse all skills](https://azendo.co/skills/)