Technical Support for Website: Updates, Monitoring, SLA
A site on Laravel 8 with PHP 7.4. PHP 7.4 exited support in November 2022. Laravel 8 — in February 2023. Vulnerabilities only close for supported versions, not for old ones. Hosting provider warned of mandatory PHP upgrade to 8.1 — and after upgrade two plugins and one library broke, site went down. This is standard scenario for projects without regular technical maintenance.
What Support Really Includes
Support isn't "answer the phone when something breaks". It's systematic prevention of failures.
Dependency updates. Composer packages, npm packages, CMS or framework itself. composer audit and npm audit show known vulnerabilities in dependencies. Dependabot or Renovate create automatic PRs with updates — support task is to verify update doesn't break something in staging and merge.
Updates come in types: patch (1.2.3 → 1.2.4, only bugfix, safe), minor (1.2.0 → 1.3.0, new features with backward compatibility, usually safe), major (1.x → 2.x, breaking changes, require testing). Ignoring updates 6+ months means accumulating technical debt: when you have to update — bigger gap, more work.
WordPress — separate topic. Platform popularity makes it prime attack target. Outdated plugins — vector #1 for breaches. Regular updates for core, plugins, themes + proper file system permissions + WAF — necessary minimum.
Monitoring: What to Track
Uptime monitoring. Basic HTTP check every minute. Betteruptime, Upptime (self-hosted), Checkly, New Relic Synthetics. Alert in Telegram or Slack on downtime — and notification on recovery. If site unavailable 10 minutes during work hours — already damage.
Performance. TTFB, LCP, INP — tracked through Google Search Console (real user data, CrUX) and synthetic monitoring (Lighthouse CI, SpeedCurve). Performance degradation often gradual — without monitoring noticed after a month when LCP already 5s.
Application errors. Sentry — standard for tracking JavaScript and PHP/Python errors in real time. Every unhandled exception with stack trace, request context, browser version. Especially important for errors users don't report — they just leave.
Database. Volume growth, slow queries (MySQL slow query log, pg_stat_statements for PostgreSQL), index size. Table without VACUUM in PostgreSQL grows to gigabytes because of dead tuples. Routine database maintenance — part of support.
Disk space and logs. Is logrotate configured? /var/log/nginx grows without limit and fills disk — classic. Automatic rotation + alert at disk > 80%.
Backup and Recovery
Backup without recovery verification — not backup, illusion of safety. We've seen cases when mysqldump created 0 byte file due to permissions error, nobody checked contents for months.
Backup scheme:
- Daily incremental database backup + media files
- Weekly full backup
- Storage: minimum 3 copies, 2 different media, 1 offsite (S3, Backblaze B2)
- Automatic backup integrity check (pg_restore --list, mysqldump verify)
- Test recovery quarterly to isolated environment
Retention policy: 7 daily, 4 weekly, 3 monthly. S3 Lifecycle rules automate deletion.
SLA: What It Means in Practice
SLA (Service Level Agreement) — specific commitments on response and recovery time:
| Priority | Situation | Response Time | Resolution Time |
|---|---|---|---|
| Critical | Site unavailable | 30 min | 4 hours |
| High | Key function broken | 2 hours | 8 hours |
| Medium | Individual page errors | 4 hours | 24 hours |
| Low | Cosmetic fixes | 24 hours | 72 hours |
SLA makes sense only with monitoring — otherwise problems learned from users, not systems. A broken button in form can lose conversion for weeks unnoticed.
Process for Content Updates
Developer shouldn't be in the loop for text fixes on page. CMS with convenient editor, access control (editor fixes content, not code), change history. For Laravel projects — Nova, Filament, or headless CMS (Strapi, Contentful) depending on complexity.
Preview before publishing, staged rollout for important changes. If editors work directly with prod — that's risk.
Typical Situations We Solve
Website hack: analyze attack vector, cleanup, strengthen security (WAF, fail2ban, restrict file system permissions). Recovery from backup takes hours, not days — if backups configured correctly.
Performance drop after update: feature flag + ability for quick rollback. Canary deploy — update 5% of traffic, watch metrics, then 100%.
Process
Onboarding: audit current state, setup monitoring and backups, document infrastructure. Then regular rhythm: weekly metrics report, monthly update review, quarterly technical audit.
Timeline
Monitoring and backup setup: 3–5 days. Regular support — ongoing contract with fixed monthly hour allocation or subscription.