05/MANAGED SUPPORT
Day two, handled by the people who wrote it.
Ongoing engineering and infrastructure support for software that is already live. Monitoring, incident response, maintenance and steady improvement, from a team that does not need the codebase explained to it.
01/When you would call us
Four situations we hear a lot.
Your application is live and working, and your entire operational plan is that someone will notice if it stops.
The engineer who built it has left, and the remaining team can keep it running but cannot safely change it.
Dependencies are eighteen months out of date and every upgrade now looks large enough to keep postponing.
You need a technical contact who already understands the system, rather than a queue where you re-explain it each time.
02/What we do
The work, itemised.
- Monitoring and alerting
- Alarms tuned to conditions your users would actually notice, routed to a person rather than a mailbox, and reviewed periodically so the noisy ones get fixed or removed.
- Incident response
- When something breaks we diagnose it, restore service, and write up what happened and what stops it recurring. The write-up goes to you whether or not you ask for it.
- Maintenance and patching
- Dependency updates, security patches and runtime version upgrades applied in small regular batches, which is the only way they stay small.
- Iterative improvement
- A steady stream of small changes — fixes, refinements, the features that never justify their own project — shipped continuously instead of saved up for a release.
- Cost and capacity review
- A periodic look at spend and headroom, so a cost drift or a resource approaching its limit gets raised before it becomes urgent.
- Technical advice on call
- Someone to think through a change with before you commit to it, who already knows the system and has no reason to talk the scope upward.
03/How we approach it
The order matters more than the list.
Learn the system properly
Support starts with an onboarding period: reading the code, mapping the infrastructure, and finding out what has broken before. We do not take on a system we cannot yet explain back to you.
Fix the alerting before anything else
Support built on alerts nobody trusts is just a slower way of hearing from customers. Alarms get tuned, routed and tested first.
Agree the boundaries in writing
What we watch, what we change without asking, what needs your sign-off, and how you reach us outside working hours. Written down at the start, so nothing depends on a shared assumption.
Work a visible queue
Requests, incidents and improvements sit in one queue you can see and reprioritise. You always know what we are doing and what we have not got to.
Review it regularly
A scheduled session covering what broke, what changed, what the environment costs, and what we would spend next month's time on. Support that never gets reviewed drifts into ticket-taking.
04/Technology
What this pillar is built with.
- Monitoring
- CloudWatch
- Alarms
- Structured logs
- Synthetic checks
- Operations
- Systems Manager
- AWS Backup
- Cost Explorer
- Trusted Advisor
- Delivery
- GitHub Actions
- Infrastructure as code
- Staged rollouts
- Coordination
- Shared issue tracker
- Slack or Teams channel
- Scheduled reviews
05/What you get
Things you can point at.
- A written scope: what is covered, what is not, and how to reach us
- Alerting that has been tested, routed to a named person and tuned to your workload
- A shared queue showing every request, incident and improvement in progress
- Incident write-ups with the cause and the preventive change, not just the fix
- Dependencies and patches kept current in regular small batches
- A periodic review covering reliability, spend and what to do next
Related services and solutions
06/Questions
Managed Support, asked about.
01What response times do you offer?
That depends on what the system needs and what you are willing to fund, so it is agreed per engagement and written into the scope rather than promised on a web page. We would rather commit to something we can meet at 3am than publish a number that looks impressive.
02Will you support software you did not build?
Yes, after an onboarding period where we read the code and map the infrastructure. If we find something that makes the system unsafe to support as it stands, we will tell you what it is and what fixing it involves before we take it on.
03Is support a monthly commitment?
Usually monthly, because the work is continuous and it lets us plan capacity. It is agreed with a defined notice period on both sides. We do not use support contracts to lock in clients who would rather leave.
04What counts as an incident versus a request?
An incident is something users are feeling right now; a request is everything else. The line matters because incidents interrupt planned work, so where it sits gets agreed in writing at the start rather than argued about during an outage.
Describe the problem.
A few lines is enough. You will get a reply from an engineer within one business day, and it will address what you actually asked.