Web application and SaaS support
Real users, a growing database, queues and migrations. We keep the application healthy and ship updates without downtime.
What's included
- Error and metric monitoring
- Background job and queue watch
- Safe schema migrations
- Dependency updates and patches
- Logging and incident forensics
- Zero-downtime deployment
- Slow query optimisation
A website has visitors; an application has users with accounts and data. That difference matters more than it sounds. When a site fails, it stops loading. When an application fails, it can keep running and quietly corrupt data at the same time. So supporting an application isn't only about whether the service is up — it's about whether it is behaving correctly.
Applications also change over time on their own, with nobody touching the code. The database grows, and a query that was instant against a thousand rows brings the server down at a million. A background queue accumulates until it overflows. A partner API deprecates the version you depend on. None of this is a sudden disaster; it's predictable degradation, visible well in advance — provided somebody is watching.
How we work
- Observability first. Before anything else we set up error tracking, metrics and log aggregation. Without it, investigating any incident becomes guesswork based on user complaints.
- Watch the background. Queues and schedulers go under monitoring. A job that stopped running usually raises no errors at all — it simply doesn't happen, which is the most insidious failure mode there is.
- Dependency updates. We update libraries on a schedule and track advisories. An application carries an order of magnitude more dependencies than a website, and much of the risk lives there.
- Schema migrations. Database changes are reversible and rehearsed on a copy first. Lost data cannot be restored with an apology.
- Zero-downtime deploys. We set up deployment so an update doesn't throw working users out of their session mid-action.
- Performance work. We track slow queries and creeping response times, and fix them before users start noticing.
What you get
An application whose problems you learn about before they arrive in your support inbox. Incidents are investigated from logs and metrics rather than from a user's recollection. Degradation shows up on a graph weeks before it becomes an outage.
If the product has a mobile client, that brings its own cycle of problems — stores, certificates, OS versions. That's mobile app support, usually taken alongside the server side. If you only need monitoring rather than full maintenance, see server monitoring setup.
Timeline
Onboarding takes a week or more: we need to understand the architecture, stand up observability, and find the bottlenecks. Then it's month to month. For applications with paying users we generally recommend round-the-clock cover — an overnight outage in a SaaS product means a morning spent working through a support queue and watching churn.
A typical scenario
Suppose a service runs an hourly background job that sends notifications. One day it stops running because the disk filled with logs. The application itself is entirely healthy: the interface loads, data saves, no errors appear anywhere. Users simply stop receiving email and gradually conclude the service is ignoring them. Background job monitoring catches that silence within the first hour, because it watches for successful completion rather than for the presence of errors.