The unglamorous work of maintaining a client website for three years

Every web agency's blog is full of launch stories. The rebrand went live. The redesign shipped. The case study that ends at the product-page reveal.

This is a different kind of story. It is about what the thirteenth month of a client website actually looks like — the work that does not make it into the portfolio, does not win awards, and, when it is done well, is invisible.

The boring stuff that compounds

The first few months after launch are exciting. You fix the rough edges the client did not notice during pre-launch QA, tune the pages that are slower than you would like, and ship the small requests that pile up in week one.

Then the work changes shape. Over a three-year engagement, the routine looks like this:

• Monthly security patching across the operating system, runtime, and framework.
• Quarterly SSL certificate rotations — even when Let's Encrypt is supposed to be zero-touch.
• Nightly database backups, with a quarterly test-restore. A backup that has never been restored is a backup that might not work.
• Annual PHP or Node version bumps, each requiring careful staging.
• Weekly log review — a twenty-minute read through errors, 502s, and slow-query logs to catch what has not fallen over yet.

None of these generates a tweet-worthy screenshot. All of them are the reason the site is still healthy in year three.

The Tuesday the cache went bad

Specifics make the point better than abstractions. Here is a composite of the kind of incident that actually happens on sites we manage.

A mid-sized e-commerce client with an EU base and a notable slice of US traffic. Their Tuesdays tend to be busy — the US-based customers shop late into their evening, which is the small hours in Bulgaria. The stack is a typical Node front-end backed by MySQL, with Redis between the two for session state, query caching, and rate limiting.

On one such Tuesday, at 02:14 Bulgaria time, the site started returning 502s intermittently. Pager fired. One of our engineers — awake because life — was on the call in under five minutes.

What we found over the next ninety minutes:

• Redis was running with Sentinel in front for high availability. A transient network blip had triggered a failover, as designed.
• The failover itself completed in about three seconds. The application's connection-retry logic did not include jitter, so every Node worker simultaneously tried to reconnect, hit the new primary at the same moment, and saturated it.
• Redis's maxmemory-policy was set to allkeys-lru. Under the reconnect pressure and sudden load on the new primary, session keys were being evicted alongside cache entries. Logged-in users were suddenly being bounced to the login page mid-checkout.
• The session failures produced a retry storm against MySQL, as the application reached past Redis for fallback reads. The MySQL connection pool exhausted. 502s cascaded from there.

The fix, in order:

1. Tightened Sentinel failover timeouts so the state change is detected faster, and blocked application calls get a clean error instead of hanging.
2. Added jittered exponential backoff to the Redis reconnect logic, so the thundering herd stops thundering.
3. Changed maxmemory-policy from allkeys-lru to volatile-lru. Cache keys have explicit TTLs; session keys do not. Under memory pressure Redis now evicts expired cache entries instead of active login state.
4. Wrote a runbook for this specific failure class, added an alert on "Redis failover detected", and scheduled a quarterly drill that simulates it on the staging cluster.

Total time to stable: 92 minutes. Post-incident review the next morning: 45 minutes. The client had a written summary by end of day. Nobody lost money, because the cart recovered gracefully once sessions were stable and the re-auth flow behaved. If we had been relying on launch-era code, they would have.

What clients actually care about

In conversations with clients who have signed on for long-term management, the things they bring up are rarely exciting:

• Uptime. Is the site up? Are customers able to buy? Did anything go wrong last month that we should know about?
• Responsiveness when something breaks. When the site does go down, how quickly are we on the phone? Do we explain what happened in language they can follow?
• No surprise bills. Do the monthly hours we bill match the work we described in the agreement? When something out-of-scope comes up, do we flag it before doing it?

None of those bullets is a growth-hack narrative. All of them are the reason clients stay with us for years.

The point

Website management is not the glamorous half of our work. It is the half that makes the glamorous half last. If you are spending real money on a new site, plan for the three years after launch, not just launch day. That is where the site earns its keep — or quietly starts decaying.