Response times and what counts as an emergency
Response time and resolution time are different things, and conflating them is how maintenance retainers turn into arguments. Response time is when a person starts work on the problem. Resolution time depends entirely on what broke, and no honest vendor can promise it in advance for a category of failure they have not seen yet.
We treat something as an emergency when the site is down, when checkout or lead capture has stopped working, when there is an active security compromise, or when a change has broken something a client can see. Those get picked up ahead of scheduled work.
A design tweak, a content update or a new page is not an emergency, even when it feels urgent. Those go into the normal queue, which is the only way the emergency queue stays meaningful. If everything is priority, nothing is.
- Site down or unreachable — monitoring alerts us directly, work starts on detection
- Checkout, forms or payments failing — treated as revenue-affecting and handled the same way
- Active malware or a compromised account — isolated first, cleaned second, root cause third
- Visible breakage after a deploy — rolled back to a working state before we investigate
- Everything else — scheduled into the normal queue with an estimate you see up front
What is not included, and what it costs when you need it
Maintenance keeps a site healthy. It does not quietly absorb new development, and a plan that claims to is either priced for the worst case or will be renegotiated the first time you rely on it. Being clear about the boundary up front is more useful than a generous-sounding scope that erodes.
- New pages, features or templates beyond the plan's change allowance
- Redesigns and rebuilds — those are project work, not maintenance
- New third-party integrations, and rework when a provider changes an API
- Migrations between hosts or platforms
- Content production, copywriting and photography
- Paid licences, hosting and third-party subscriptions, which stay in your name
Any of it can be done — most of it is work we do every week. It gets quoted separately and approved before it starts, so nothing appears on an invoice you did not agree to. Where a request keeps recurring, we will suggest moving up a tier rather than repeatedly billing overflow.
How we monitor, and what you receive each month
Monitoring runs against the live site continuously and alerts us rather than you. Uptime checks confirm the site is reachable, error tracking catches failures that do not take the whole site down, and we watch Core Web Vitals on every plan so a slow decline gets caught before it shows up in rankings.
Updates never go straight to production. They are applied on staging, checked, and only then released — which is the single practice that separates maintenance from gambling with a client's site every month.
The monthly report says what was updated, what was found, what was fixed, how much of your change allowance was used and what is worth doing next. It is written to be forwarded to a client, which matters if you are reselling this under your own brand.
