Cloud & delivery / Capability
Monitoring & support.
Logs, metrics and alerts that show problems early, with agreed support for after launch.
Review your release process
When to bring us in
Sound familiar?
- We find out something is broken when a customer emails us.
- We get so many alerts that we’ve started ignoring them.
- When something fails, the logs don’t tell us what happened.
The cost of leaving it
Customers report problems before the team sees them. Without agreed support, an issue on a Friday evening waits for whoever happens to check their messages.
Why us
What we bring to monitoring & support.
Infrastructure kept in code
Our own products run on AWS with infrastructure defined in Terraform, so environments can be reviewed and rebuilt.
Data kept apart by design
In SoulCare, each care provider has its own PostgreSQL database rather than sharing tables with everyone else.
Accounts set up in your name
Cloud accounts and databases are yours from the first day, not something to transfer at the end.
What the work includes
Know about the problem before your customers do.
We decide what healthy looks like for your product, then instrument it: structured logs, a small set of meaningful metrics and alerts that point at a cause. Each alert has a runbook. Support after launch has an agreed scope, response expectations and a regular review of what went wrong and why.
Logging and tracing
Structured logs and request traces that let you follow a problem across services.
Metrics and dashboards
A small set of measures that show whether the product is working for its users.
Alerts and runbooks
Alerts tied to real problems, each with written steps for the person who responds.
Ongoing support
Maintenance, fixes and improvements within an agreed scope and response arrangement.
Use cases
Projects we take on.
Alerts for a live platform
A product with no alerting given a short set tied to failed sign-ins, slow pages and stuck background jobs.
Support after another team’s build
An application built elsewhere reviewed, instrumented and placed under an agreed support arrangement.
Cutting alert noise
An alert list people have learned to ignore, trimmed to the ones that need action and given runbooks.
What you get
Outputs you can review.
- Logging and tracing setup
- Service dashboards
- Alert rules with runbooks
- Incident review template
- Support scope and escalation plan
Technologies we use for this
Where it matters
- Health & social care Where each care provider has its own database and access rules, environments, backups and schema changes have to be managed per provider.
- Medical education A training app on the app stores and the web needs one pipeline that ships every platform from the same tested commit.
- Property & field services Field apps in daily use need releases that don’t interrupt a worker mid-job, and alerts when uploads or payments start failing.
- Fintech & professional services Infrastructure changes need review and a record of who approved them; version-controlled code and pipeline approvals give you both.
Where AI helps
Useful, on a short leash.
Grouping alerts and errors
Cluster related errors and log lines into one incident, so the on-call person sees the pattern rather than the noise.
AI workflow automation ↗Drafting incident notes
Draft a timeline from logs and chat for the engineer to correct, so write-ups happen while details are fresh.
AI workflow automation ↗
Where it stops: Restarting services, rolling back or contacting customers stays with the person on call.
What’s changing
Shifts to plan for.
June 2026
Amazon Linux 2 reaches end of life
Amazon Linux 2 reached end of life on 30 June 2026. Lambda runtimes built on it, such as Python 3.10 and 3.11 and older Java, get limited patches until their own deprecation dates.
April 2026
Lambda deprecates Node.js 20
Lambda stopped patching the nodejs20.x runtime on 30 April 2026. Creating functions on it is blocked from 29 July 2027 and updating them from 31 August 2027.
April 2026
MySQL 8.0 reaches end of life
Oracle moved MySQL 8.0 to Sustaining Support, so Oracle no longer releases security fixes for it. Oracle recommends moving to MySQL 8.4 LTS or 9.7 LTS.
Process
How the work runs.
Define healthy
We agree what working looks like in user terms, such as records saved or payments completed.
Instrument the gaps
Logs, traces and metrics go where a failure today would leave you guessing.
Write the runbooks
Each alert gets a page saying what it means, what to check first and who to call.
Review on a schedule
Incidents and near misses are reviewed at set intervals, and the fixes go into the backlog.
Cost
What shapes the estimate.
Existing visibility
Products with structured logging already in place need less instrumentation.
Hours of cover
Support in business hours is a smaller commitment than evenings and weekends.
Rate of change
Systems that ship often need more attention than ones that rarely change.
Ways to work together
A first, fixed stage
Discovery, a prototype or a technical review with agreed outputs, so the next decision is made with something concrete in hand.
Delivery in phases
The build split into releases, each with a scope you review and approve before it starts.
Ongoing engineering
An agreed scope for support and improvements after launch, with response expectations written down.
Common questions
Before you get in touch.
Can you monitor a product you didn’t build?
Yes, after a review of the application and its hosting. Instrumenting it may need code changes, which we scope with you.
What response times do you offer?
Response expectations, hours of cover and escalation are agreed for each engagement. We don’t offer a default 24/7 commitment.
What affects the cost of support?
The size and condition of the system, hours of cover, expected change volume and how much monitoring is already in place.