24/7 Support SLA: What It Should Actually Cover
24/7 support in a website service level agreement (SLA) should name three services, each with its own clock. Monitoring and urgent incident response, such as a site outage, should run around the clock on every site. Routine requests belong in business hours. That window, plus the monthly hours you buy, drives most of the cost.
Many of the requests for proposals (RFPs) we answer for website support ask for "24/7 support" and never define it. Each bidder then guesses, and the prices stop lining up.
Key Takeaways
- A 24/7 support SLA bundles three services: monitoring, urgent incident response, and routine requests.
- Monitoring and urgent response should run 24/7. Mandiant's M-Trends 2026 puts the mean time to exploit at minus seven days.
- Routine requests rarely need a night shift, and their hours window drives most of the price.
- Google's SRE book ties roughly 70% of outages to live-system changes, so good release habits keep night alerts rare.
What Should a 24/7 Support SLA Actually Cover?
A 24/7 support SLA should split the promise into three services, each with its own hours, targets, and price. Only monitoring and urgent response need to run around the clock.
Table: The three services inside a 24/7 support SLA
Service | What it covers | Hours it should run | What drives the cost |
|---|---|---|---|
Monitoring | Automated checks on uptime, errors, speed, and security alerts | 24/7, on every site | Tools and setup, not staff hours |
Urgent incident response | Site down, a key path broken, or an active security threat | 24/7 | Being ready to act, made cheaper by alerts and time zones |
Routine requests | Content fixes, small changes, editor help, and planned updates | Business hours | The window length and the monthly hours you buy |
Cost climbs mainly in the routine row as the clock gets longer. To split support by type of work instead, see our nonprofit Drupal support RFP guide.
What Drives the Cost of 24/7 Website Support?
Staffed hours drive the cost of support. A week has 168 hours, and a 9-to-5 weekday window covers 40 of them, or about 24%. Round-the-clock routine coverage means staffing all 168, more than four times as many.
Two levers set most of the price:
- The business-hours window for routine work, such as 8 or 12 hours a day, or around the clock.
- The monthly hours allocation, which is how many hours of routine work you buy each month.
Hosting can also shift the price. A site on generic infrastructure often needs a higher support tier than one on a Drupal-optimized platform.
Why Should Monitoring Run 24/7 on Every Site?
Monitoring should run around the clock on every site because availability is a measurement. If no one measures the site at 3 a.m., no one can prove a 99.9% uptime promise was kept. Our higher ed SLA guide shows how little downtime that figure allows.
Website monitoring means automated checks on uptime, errors, page speed, server load, and security alerts. Google's Site Reliability Engineering (SRE) book sets a high bar: a good alert should never need a person to work out what it means.
A cached page can look fine while the server behind it fails, so monitor the origin server directly. Because monitoring also starts the SLA response clock, it is the base layer of support.
Should Urgent Incident Response Run 24/7?
Urgent incident response should run 24/7, because a broken site does not wait for office hours. In most SLAs, an urgent incident is the top tier, often called priority one.
In our experience, overnight incident response adds little to the price. Automated alerts and a team spread across time zones do most of the work. A 3 a.m. alert in New York arrives mid-morning in Amman. Vardot's support team works 24/7 shifts with on-call engineers and responds to alerts within an hour.
What Counts as a Priority-One Incident?
A priority-one incident usually means one of these:
- The site is down or unreachable for most visitors.
- A critical path is broken, such as donations, checkout, applications, or login.
- An active security threat, such as a flaw being exploited or data being exposed.
Everything else can wait for business hours. A long priority-one list is a 24/7 routine contract in disguise, and it gets priced like one. Also agree on who decides severity. Our 10 questions for enterprise Drupal support SLAs cover that step.
Does Drupal Security Work Need After-Hours Cover?
Routine Drupal security work runs on a published schedule, so it rarely needs a night shift. Core security fixes come out one Wednesday a month, usually the third, and contributed module fixes on any Wednesday.
Releases land between 16:00 and 22:00 UTC. That is daytime on US Eastern time, but evening in Europe and the Gulf. Either way, routine patches can be planned like other workday tasks. The exception is a highly critical flaw already being exploited, which can ship outside the window. Treat that as priority one.
Attacks now move faster than patches. Mandiant's M-Trends 2026 report estimates the mean time to exploit a flaw at minus seven days, so attackers often strike before a patch exists. That is the case your 24/7 priority-one cover is for.
Drupal 10 reaches end of life on 9 December 2026, and its security fixes stop. After that, no official patches ship at any hour, so plan the Drupal 10 to 11 upgrade as its own project.
When Do Extended Hours for Routine Requests Pay Off?
In our experience, extended hours for routine requests pay off mainly for News websites and sites with a donation feature, especially at the times of campaigns or crises where a 9 p.m. fault costs sales or readers by morning. Most enterprise, nonprofit, and university sites can wait until 9 a.m. for a content fix. Extended hours cost the same every week, whether or not anyone files a ticket at night.
A middle path is to stretch the window for named weeks only, such as a year-end giving campaign or a registration period. You pay for longer hours when traffic needs them, not all year.
Do You Need Extended Hours for Routine Requests?
Price an extended window if either of these is true:
- Your site earns money or donations around the clock.
- A small fault left overnight would cost more than a month of extended hours.
If only your traffic peaks or your editors fall outside your main time zone, a longer window for those regions may be enough.
Can You Stay with Business Hours?
Yes, if content fixes can wait until morning, your peaks are predictable, and your priority-one list is short. Then stretch a standard window for peak weeks and spend the savings on monthly hours.
Our View: Why Dropping Overnight Cover Rarely Saves Money
Teams that cut "24/7" to save money usually cut the wrong part. They drop overnight incident cover, which costs little, and keep a long business-hours window, which costs a lot. The bill barely moves, and no one is ready to act on an outage at night.
Vardot's support plans run from monitoring only up to enterprise tiers, each with its own service-hours window. We sell both business-hours and extended plans, so our advice does not depend on which you buy. The right plan depends on your traffic and risk.
What Should Your RFP Say Instead of "24/7 Support"?
Replace the single phrase with three sentences, one per service, and fill in your own numbers.
- Monitoring: "The vendor monitors uptime, errors, performance, and security alerts 24 hours a day, 7 days a week, and reports availability each month."
- Urgent incidents: "Priority-one incidents, defined as [your list], receive a response within [target] at any hour, every day of the year."
- Routine requests: "Routine requests are handled [8 a.m. to 6 p.m., Monday to Friday, in our time zone] within [number] hours per month."
Each line now has its own clock and price, so the bids you get back compare line by line.
How Do Release Habits Reduce After-Hours Incidents?
Good release habits keep urgent incidents rare, so the 24/7 cover you pay for mostly sits unused. Google's SRE book finds that roughly 70% of outages come from changes to a live system.
A simple habit is to avoid Friday deployments. Ship early in the week and early in the day, when the full team can watch and roll back. Freeze changes before known peaks, like a giving campaign.
The SRE book names three practices that make changes safer: roll out gradually, catch problems fast, and roll back safely. At Vardot, AI helps us write an automated test for every code change, so one fix does not quietly break something else. Ask your vendor when they deploy and how they undo a bad release.
What Should You Check Before Your 2027 Support Renewal?
Before you renew or issue an RFP, check how your current SLA defines "24/7." If it does not split the three services, you may be paying for hours you do not use.
We review support scopes and RFP drafts with digital and procurement teams, whether or not we bid. Talk to us about your support scope, and we will map where your support hours actually go.