Your Site Went Down At 11pm On A Saturday — Who Did You Actually Call?
The hosting status page is green. Your maintenance provider's support email auto-replied with 'we will respond within 24 hours'. Your phone has voicemails from three customers and a partner asking why the site is showing a database error. By Sunday morning the team has worked out the bug, but the maintenance contract you signed in good faith never specified what the response time actually meant. This is the page that walks through what real website maintenance covers, what it costs, and how to evaluate a provider before the next incident.
BOOK YOUR 30-MIN CALL SEE WORDPRESS-SPECIFIC PLANS12,000+ sites under maintenance at Seahawk Media WordPress, Next.js, Astro, Remix, headless Written SLA on response + recovery Quarterly fire-drill incident testing
The six things real maintenance includes
Security patching across the full stack. CMS core (if WordPress, Drupal, etc.), framework dependencies (Next.js, Astro, npm packages), runtime (Node, PHP), and any third-party services in the request path. The audit runs weekly; critical patches ship within 24 hours; non-critical roll up monthly. The maintenance providers who do this badly let CVEs sit for weeks; the ones who do it well have automated dependency-update PRs gated by regression tests.
Daily backups with verified restore tests. Backup-without-restore-test is theatre. Real maintenance includes a weekly automated restore to a staging environment that confirms the backup actually works. The first time you discover your backups are corrupted should not be the day you need them.
Uptime monitoring with multi-region checks. Sub-5-minute alert thresholds. Multi-region monitoring (UK + US + Asia at minimum) so you do not get woken at 3am by a false positive from a single broken probe. Status pages that customers can subscribe to. The cheap end of maintenance uses one-region monitoring and misses regional outages entirely.
Performance monitoring on Core Web Vitals. Field data via Chrome User Experience Report (CrUX), not just lab-data Lighthouse scores. Monthly reports on LCP / FID / CLS / INP. Triggers when any metric drops below the green threshold. The maintenance providers who only report lab-data Lighthouse scores are missing the metric Google actually uses for ranking.
Dependency updates with regression testing. npm-audit, security advisories, framework version upgrades. Each update goes through staging with automated regression tests before production. Most providers either skip updates entirely (and you accumulate technical debt + security risk) or push them straight to production (and you accumulate bug reports).
Incident response with written SLA. P0 (site down): 30-minute response, 4-hour resolution target. P1 (degraded): 2-hour response, 24-hour resolution. P2 (cosmetic): next-business-day. Quarterly fire-drill where you trigger a test incident and the provider has to hit the SLA on the practice run. Without the fire-drill, the SLA is just a paragraph in a contract.
The three pricing tiers, honestly
Entry (250-500 GBP/month). Updates, backups, uptime monitoring, best-effort support during business hours. The right tier for a 5-15 page marketing site with low traffic and no critical revenue dependency. Below 250 GBP/month, the maths only works if the provider cuts corners — usually on backup verification or security patching speed. If you see "$50/month maintenance" pitches, run.
Mid (500-1,200 GBP/month). Everything in entry, plus proactive performance tuning, security hardening, monthly performance reports, 4-hour SLA on P0. The right tier for a 25-100 page content site, B2B SaaS marketing site, or low-volume ecommerce. Most professional-services and agency-marketing sites land here.
High (1,500-3,500 GBP/month). Everything in mid, plus 24/7 on-call, sub-hour SLA on P0, dedicated developer hours for ad-hoc custom work, quarterly architecture reviews. The right tier for ecommerce doing 50k+ GBP monthly revenue, regulated industries (healthcare, finance), or sites where downtime has measurable revenue cost.
The pricing scales with traffic and SLA tier, not page count. A small site with mission-critical revenue dependency belongs in the high tier; a large content site that can tolerate 4-hour outages belongs in the mid tier.
What this page is not — distinct from /wordpress-support/
/wordpress-support/ is the WordPress-specific version of this conversation. The deliverables overlap on the foundations (security, backups, uptime, performance) but the WordPress page covers plugin-compatibility patterns, WordPress-specific incident shapes, the WordPress-hosting market, and care-plan economics tuned to the WordPress business model. If your site is on WordPress, that page is closer to your actual brief; if your site is Next.js, Astro, Remix, headless commerce, or mixed-stack, this page is the right starting point.
For London-specific support, /wordpress-support-london/ covers the geography. For redesign + maintenance bundles, /website-redesign/ walks through the rebuild side and how to ship a maintenance contract alongside the new site.
When website maintenance is the wrong investment
Two categories. Sites that are about to be redesigned or re-platformed within 3 months — paying for ongoing maintenance on a site that will be replaced is rarely the right call; bridge with a one-month emergency-incident-only retainer instead. Personal blogs and side-projects with zero revenue dependency — the maths of paid maintenance assumes downtime has a cost; if the site going down for a weekend is genuinely fine, free uptime monitoring + a quarterly self-update is the right answer. Most other shapes of business benefit from real maintenance; the question is which tier.
Frequently asked questions
What does website maintenance actually include?
Six things, every month. Security patching across the stack (CMS, plugins, packages, runtime). Daily backups with verified restore tests. Uptime monitoring with sub-5-minute alert thresholds. Performance monitoring on Core Web Vitals field data. Dependency updates with regression testing. Incident response with a written SLA on response and recovery time. If a maintenance contract does not list those six in writing, you are paying for hosting plus hope, not maintenance.
How is this different from /wordpress-support/?
Different scope. /wordpress-support/ covers WordPress sites specifically — the LAMP stack, plugin compatibility, the WordPress-specific incident patterns. Website maintenance is platform-agnostic — it covers WordPress, Next.js, Astro, Remix, custom Node services, static sites, headless commerce. The work overlaps on the foundations (uptime, backups, security) but diverges on the application layer. Pick the WordPress-specific page if you are on WordPress; pick this page if your site is modern-stack or mixed.
How much does website maintenance cost in 2026?
Honest pricing. Entry tier (250-500 GBP/month) covers updates, backups, uptime monitoring, best-effort support during business hours. Mid tier (500-1,200 GBP/month) adds proactive performance tuning, security hardening, monthly performance reports, 4-hour SLA. High tier (1,500-3,500 GBP/month) adds 24/7 on-call, sub-hour SLA on P0 incidents, dedicated developer hours for custom work, quarterly architecture reviews. The price scales with traffic, complexity, and SLA tier; a five-page marketing site does not need 1,500 GBP/month, an ecommerce site doing six-figure monthly revenue absolutely does.
How fast should website maintenance respond when the site goes down?
A real care plan responds within 30 minutes for a P0 outage and resolves within 4 hours for typical incidents. P1 (degraded but functional) gets 2-hour response and 24-hour resolution. P2 (cosmetic or non-critical) gets next-business-day. If a provider does not commit to specific response and recovery times in writing — and does not run a quarterly fire-drill that proves they can hit those numbers — treat it as marketing rather than maintenance.
Should I use a managed host or a separate maintenance contract?
Both, in most cases. Managed hosts (Vercel, Netlify, Kinsta for WordPress, WP Engine, Pressable) handle infrastructure — server uptime, caching, OS patching, edge network. A maintenance contract handles the application layer — code patches, plugin compatibility, security incidents, custom development, the runbook for when something breaks. They are complementary, not substitutes. The teams that try to use a managed host as a substitute for application maintenance discover the gap during the first real incident.
What about modern-stack sites — Next.js, Astro, Remix?
Maintenance for modern-stack sites is genuinely different from WordPress maintenance. The work shifts from "WordPress core + plugin updates" to "npm package security audits + framework version upgrades + runtime monitoring". Vercel and Netlify handle most of the infrastructure layer. The application layer needs npm-audit reviews, framework upgrade paths planned, and the typical Next.js / Astro pitfalls (build cache invalidation, edge function regressions, ISR drift) monitored. Most maintenance providers built for WordPress do this badly; the few who do it well are usually small shops with strong modern-stack practice.
The next conversation
Bring three things. Your site URL plus the stack (WordPress, Next.js, Astro, custom). The current uptime / incident pattern over the last 12 months — even rough numbers (one outage in six months vs three outages a quarter) tell us which tier fits. The revenue or business dependency on the site staying up — five customer enquiries a week is a different brief from sixty thousand monthly ecommerce revenue. By the end of 30 minutes you will have the right tier, the price, and the SLA tier that fits your actual exposure.