TL;DR: Structure your endpoints into pilot, production, and critical tiers so patches move through controlled phases rather than hitting everything at once. Automate deployment and remediation where it makes sense, then use deployment and vulnerability data to catch failures early. PDQ handles the targeting and scheduling and surfaces the devices that need follow-up — you set the rules, and the automations run accordingly.
An effective patching schedule separates endpoints into deployment groups and moves updates through those groups on a defined cadence. Test on a pilot group first, monitor results, roll successful patches to production, and handle critical systems and exceptions separately. Verify deployment and remediate failures. PDQ can automate most of this process.
What is a patching schedule?
A useful schedule accounts for patch severity and urgency, endpoint criticality and business function, business hours and maintenance windows, testing requirements before broad rollout, restart tolerance and user impact, offline or intermittently connected devices, and deployment verification and exception handling.
Without a schedule, patching becomes reactive. With one, it becomes repeatable. For more background on how scheduling fits into the bigger picture, see what is patch management.
Automate patching with PDQ Connect
Keep Windows & macOS devices patched and secure from the cloud.
What should you consider before creating a patching schedule?
Know your environment before choosing a cadence. The schedule that works for a 9-to-5 office looks nothing like the one for a 24/7 healthcare operation.
Gather this information first.
Know hours of operation: User activity patterns and safe restart windows define the boundaries of your patching schedule.
Identify peak business periods: Month-end close, enrollment windows, and seasonal rushes all reduce downtime tolerance.
Note existing maintenance windows: Patching schedules should align with the windows already in place.
List critical endpoints: Servers, point-of-sale systems, and production machines are where unplanned downtime creates real problems.
Account for remote and intermittently connected devices: Laptops that spend much of their time off-network need special handling.
Inventory operating systems and applications: Windows, macOS, and third-party apps may each require different handling.
Determine restart tolerance: Some environments can force restarts, while others require user coordination.
Consider vulnerability severity: Critical CVEs may need faster deployment than routine updates.
Document compliance requirements: Some regulations specify patching timelines you must meet.
This isn't busywork. These answers determine whether your schedule survives contact with reality.
How should you group endpoints for patching?
Grouping endpoints is the foundation of phased patching. Without groups, every patch is either deployed everywhere at once, which is risky, or deployed manually device by device, which is unsustainable.
PDQ lets you organize endpoints into groups based on device attributes so different groups can follow different schedules automatically.
Pilot group
A small but representative group that receives updates first. Include IT-owned machines, technically capable users who can report issues, and devices that represent your common hardware and software configurations.
The pilot group exists to catch problems before they reach the broader population. If a patch breaks something, you'd rather learn that on 20 devices than 2,000.
Production group
The majority of standard endpoints. Updates reach this group after pilot testing shows the patch is stable.
This is where most of your devices live. The goal is predictable, scheduled deployment, not emergency pushes at 2 a.m.
Critical or exception group
Devices with special requirements are in this group, such as servers with strict uptime needs, systems running sensitive applications, endpoints subject to regulatory constraints, or machines that can't be restarted during business hours.
These devices may need different maintenance windows, additional testing, or manual approval before patches deploy.
How do you build an automated patch testing and deployment workflow?
An automated patching workflow uses endpoint groups to test patches on a small set of devices first, deploy approved updates to production on a schedule, and monitor results for failures or exceptions. Endpoint management tools like PDQ automate the heavy lifting without requiring admins to build everything from scripts.
Here's the workflow:
1. Identify the updates that need to be deployed
Start by determining which applications or operating system updates require attention. This might come from vendor release announcements, vulnerability scans, or PDQ's vulnerability detection showing which CVEs currently affect your managed devices.
2. Deploy patches to your pilot group
Push newly approved patches to your pilot group first. With PDQ, you can target your pilot group specifically and schedule deployments to run automatically so that you don't need to initiate each update manually.
3. Monitor the pilot deployment
Give the pilot deployment time to surface problems. Look for installation failures, application crashes or compatibility issues, restart problems, and unexpected endpoint behavior.
A successful installation does not automatically prove a patch is safe. Watch for user-reported issues too.
4. Roll the patch out to production
Once pilot results meet your criteria, deploy the update to your broader endpoint population. PDQ can automate this on a schedule so production deployments happen at your defined cadence without manual intervention.
5. Verify deployment status
Confirm which endpoints successfully installed the update. PDQ's reporting shows deployment results across your groups so you can identify devices that still need attention.
6. Remediate exceptions
Handle failed installations, offline endpoints, devices that missed their maintenance window, and systems requiring manual intervention. Automation does not mean nothing ever goes wrong; it means you can identify and address exceptions systematically.
For more on building a complete program around this workflow, see how to build a patch management plan.
What does a practical patching schedule look like?
Most environments need at least two schedules: a standard monthly cycle for routine updates and an accelerated track for actively exploited vulnerabilities. The templates below cover both. Treat the day counts as starting guidelines — the right cadence depends on your risk tolerance, environment complexity, and how your organization defines acceptable exposure time.
Example monthly patch cycle
The monthly cycle below is an example default cadence. Adapt the pilot and critical-systems windows to fit your environment — security-focused teams often compress the pilot window, while highly regulated environments extend the critical systems window to allow more testing.
Phase | Example timing | Group | What happens example |
|---|---|---|---|
Pilot deployment | Day 1–2 after release (Patch Tuesday +1 is an example anchor) | Pilot — 5–10% of fleet: IT machines, technically capable volunteers, representative hardware | Patches deploy automatically to pilot targets |
Pilot monitoring | Day 2–7 | Pilot | Watch for installation failures, application crashes, unexpected reboots, and user reports |
Production rollout | Day 7–10 | Production — remaining standard endpoints | Automatic scheduled deployment; no manual trigger required |
Critical systems | Day 10–14, inside a designated maintenance window | Servers, production systems, regulated endpoints | Controlled deployment; may require change-ticket approval before it runs |
Exception sweep | Day 14–30, ongoing | Devices that failed, were offline, or missed their window | Retry queue, investigation, escalation for persistent failures |
Example emergency track for actively exploited vulnerabilities
When a critical CVE is being exploited in the wild, a standard cadence is often too slow. Use an accelerated track that runs in parallel with normal operations.
Phase | Example timing | Group | Action example |
|---|---|---|---|
Triage | Day 0 — CVE disclosed | — | Assess exploitability, actual exposure, and whether compensating controls buy time |
Emergency pilot | Day 0–1 | Pilot | Deploy immediately; monitor for 24 hours |
Production push | Day 1–3 | Production | If pilot is clean, deploy without waiting for the standard window |
Critical systems | Day 3–5 | Servers, production machines | Accelerated maintenance window; notify stakeholders in advance |
For details on running an out-of-band patch response, see out-of-band patching framework.
How do you handle devices that miss a patching window?
Devices miss patching windows constantly. This is not a failure of the schedule — it is a predictable outcome that the schedule needs to account for. According to PDQ's State of Sysadmin research, 51% of sysadmins say timely security patch implementation takes up too much time, and a significant share of that time is spent chasing stragglers manually.
The operational goal is not zero exceptions. It is knowing which exceptions exist, why they exist, and having a defined path to resolve each category without human intervention for the routine ones.
Offline devices
The most common miss is a device that was simply powered off or disconnected during the deployment window. The right behavior is automatic retry when the device comes back online — not a calendar reminder to check on it next week.
Design your workflow so pending deployments are queued and execute at next check-in. That said, you may want to track is duration: A device offline for a scheduled maintenance window is very different from a device that hasn't checked in for three weeks.
Traveling laptops and remote endpoints
Laptops that spend most of their time off the corporate network can accumulate patch debt every week they're away. Traditional management tools that depend on LAN connectivity simply cannot reach them.
PDQ manages remote and traveling devices over the internet without requiring a VPN. That means your patch schedule applies to remote endpoints the same way it applies to office machines — they join the same deployment queues and receive patches regardless of where they're connecting from. Without internet-based management, remote devices become a chronic exception that grows every time someone travels.
Failed installations
A failed deployment is not the same as a missed window. Failures may need full investigation, not just retry, because retrying without understanding the cause often produces the same result.
Here are some common causes and remediation paths:
Pending reboot required: A previous update is waiting on a restart before new software can install. Schedule or prompt a reboot, then retry.
Insufficient disk space: The patch cannot stage. Clean disk space and retry.
Conflicting process or application lock: Antivirus, a running application, or a file lock is blocking installation. Review the error log, address the conflict, and retry.
Permission errors: The deployment agent lacks rights to the target path. Check service account configuration.
Compatibility block: The patch itself is incompatible with a specific software version or configuration on that device. This needs manual investigation and may require a documented exclusion.
Missed maintenance windows
A device can be online and reachable but still miss its deployment window — because it was in active use, a user deferred a restart, or the scheduled job fired while the machine was locked on a video call. These devices should be captured by the next scheduled window automatically.
Define explicitly how long a device can remain unpatched before it moves from "will be caught at next window" to "needs manual attention." Example thresholds: one week for standard production endpoints, 24–48 hours for high-risk or regulated systems.
Retry and escalation strategy
Not every exception should land in a human's queue. Build a tiered response:
Retry or redeploy: Failed or incomplete deployments are retried based on the organization’s patching cadence, device availability, or remediation workflow.
Flagged for review: After a defined number of failed attempts, the device is flagged for review so repeated failures don’t go unnoticed.
Escalated for investigation: Persistent failures are investigated using deployment details, error messages, and output logs to identify and remediate the cause.
Documented exclusion: Some devices may have an approved reason for not receiving a specific patch, such as a known compatibility issue. These exceptions should be explicitly documented and periodically reviewed.
The exceptions backlog is one of the clearest signals of process health. If it grows week over week, the schedule is not working. If it stays flat or shrinks, the retry and escalation logic is doing its job.
How do you verify that your patching schedule is working?
Deploying patches and verifying patches are different activities. A deployment record that shows "succeeded" means the installation attempt completed — it does not always confirm the device is now secure. Process verification means looking at the health of the overall patching operation, not just checking individual deployments.
The metrics that matter
Tracking the right metrics tells you whether your patching process is actually working. Focus on the numbers that expose coverage gaps, stale exceptions, and schedule failures before they become security incidents. The six metrics below give you a clear operational picture of process health across your entire fleet.
Patch coverage rate
The percentage of managed devices that have a required patch installed. This is the headline number. Track it per group (pilot, production, critical) and per severity (critical, high, medium). A fleet-wide coverage rate that looks acceptable can hide a segment in serious trouble. For instance, a 95% coverage rate sounds good until the 5% unpatched are all your production servers.
Time-to-patch (TTP)
This is the number of days between a patch being available and it being installed across your fleet. Track TTP as a distribution rather than an average. The 90th percentile — how long the tail of unpatched devices persists — matters more than the median. CISA's Known Exploited Vulnerabilities catalog identifies vulnerabilities with evidence of active exploitation. Treat KEV status as a high-priority risk signal and set aggressive time-to-patch targets accordingly.
Exception volume and trend
How many devices are in your exception backlog at any given time, and is that number growing or shrinking? A stable backlog may be manageable. A growing backlog means your schedule is not keeping pace with the devices that need follow-up. Week-over-week exception volume is a leading indicator of whether the process is sustainable.
Recurring failures
A device that fails three or more consecutive deployments may be signaling an environmental problem — hardware, configuration, or compatibility — not a patch problem. Identify these devices and route them to investigation rather than continuing to retry.
Missing patches by severity
Break down unpatched devices by risk, not severity alone. Consider factors such as known exploitation, CVE severity, asset criticality, and exposure. Twenty missing medium-severity patches may represent less risk than one actively exploited vulnerability on an internet-facing production system. Prioritize the exception report by risk, not by volume.
Schedule adherence
Are deployments actually running when scheduled? A job that never triggered — not a device that failed to install, but a deployment that never fired — could indicate a problem with the scheduling infrastructure itself. This is easy to miss if you only look at installation outcomes.
Using PDQ's reporting for process health
PDQ surfaces deployment status across your entire managed fleet without requiring manual queries to individual endpoints. You can see which targeted devices completed successfully, which failed, and which are still queued or in progress. Connect also surfaces vulnerable devices and lets you scope and organize reporting by factors such as device group, vulnerability severity, and time range.
Use that data to generate a weekly process health snapshot: coverage rate, exception count, new recurring failures, and TTP trend. For compliance purposes, this reporting also documents that patching is actually happening (not just scheduled, but executed and verified), which is what most audit frameworks require.
For more on the operational side of this, see patch management best practices.
How can PDQ automate patching schedules?
The six-step workflow above describes what needs to happen every patch cycle. PDQ's value is in automating the handoffs between steps so the cycle runs without requiring an admin to initiate each stage manually — and without building the targeting logic, scheduling infrastructure, or retry behavior from scripts.
Dynamic targeting that stays current
In PDQ, device groups update automatically based on the device attributes you specify: operating system, software inventory, or any other managed property. When a new device enrolls, it joins the right group immediately. When a device's attributes change, it moves to the appropriate group without manual reconfiguration. This is the difference between a static list of hostnames that goes stale and a live query against your actual inventory.
Scheduled deployments that run without a trigger
Set your cadence once. PDQ runs deployments against each group on the schedule you define — pilot on Tuesday morning, production the following Monday, critical systems during the Saturday maintenance window. These deployments run without someone logging in to start them.
Automatic retry for offline devices
When a device is offline at deployment time, PDQ retries automatically when the device checks in. You do not maintain a manual list of who missed the window; the system manages the queue.
Visibility without auditing every endpoint
PDQ's reporting shows deployment status across the fleet in one console — successful, failed, pending, and missing — without requiring you to query each machine or cross-reference spreadsheets. Exceptions surface automatically rather than hiding until someone goes looking.
Vulnerability detection connected to deployment
When PDQ identifies a CVE affecting your managed devices, you can move from detection to remediation without switching tools. For vulnerabilities with a recommended PDQ package, you can deploy the fix directly or create an automation that applies the remediation to vulnerable devices automatically — including devices that become vulnerable later.
Does AI change how you manage patching schedules?
PDQ's Model Context Protocol (MCP) server lets MCP-compatible AI assistants query and interact with your PDQ environment through natural language. For teams that use AI tools as part of their daily workflow, that means questions like which devices are missing an update, which vulnerabilities are affecting your fleet, or which deployments failed can be answered without opening the PDQ console.
MCP doesn't require you to change your existing patching cadence, deployment rings, or automation schedules. What it changes is how you interact with the process. Instead of navigating through the console to investigate patch status or deployment results, you can ask an AI assistant for the information directly from your live PDQ data. And, depending on your PDQ permissions, the assistant can also take actions such as starting deployments, remediating vulnerabilities, and creating or updating automations.
A patching schedule is a process, not a date
A patching schedule does not end when you pick your deployment windows and write them down. The schedule is an operating process with tiered groups, defined cadences, retry logic, exception handling, and verification metrics. It requires ongoing adjustment as the environment changes.
Endpoints move between groups. Applications get added that need special handling. New vulnerability classes demand faster response times. Maintenance windows shift with business needs. The organizations that patch reliably are not the ones with the most elaborate initial plan; they are the ones who built feedback loops into the process. They measure coverage, identify what is not working, and tighten the workflow over time.
The practical target is a schedule that runs largely without intervention, surfaces exceptions clearly, resolves most of them automatically, and produces documented evidence that your environment is actually covered. That is not a one-time project. It is a recurring process that gets faster and quieter the more you automate and the more you measure.
PDQ provides the targeting, scheduling, retry, and reporting infrastructure so that process takes less of your time — and delivers more consistent results than a manually driven one.
