Developing a backend application, building it, testing it and deploying it — that's the fun part. It's what most people picture when they imagine what developers do all day. In the ideal case, the result is an app that people will actually use. And while investors wish as many people as possible would use it, developers might sometimes wish there weren't quite so many.
Why? Because running in production brings one fundamental commitment: that the app will be available and will work without errors. And that never happens on its own.
Nothing tests your application like live production traffic. And that traffic usually doesn't stay the same — it grows steadily. With every additional request come additional risks. Deploying to production is really where the whole thing begins. The assignment is clear: keep the app running without errors.
Monitoring, or how to find out that something's on fire
So how do we actually find out that an app isn't working the way it should? One option is to wait until users start complaining. Ideally by flooding support — or, even better, by abandoning our app altogether.
That's probably not the scenario we'd want to run a modern service by. Let's leave reactive firefighting in the past.
We want to know before the user does — ideally before anything even breaks. That's where our preferred approach comes in: we actively watch the application and step in early when a problem is approaching. This approach has a name: application monitoring.
What to monitor
What exactly needs to be watched depends on the application itself. For a typical web application, we'll most often care about application servers, databases, connections to external web services, network components, other communication components, caches, data storage, backups, running costs, but also vulnerabilities in libraries, billing and more.
A few concrete examples to give you an idea:
- The application reports errors – something probably isn't working as it should.
- The application is slow and maxes out resources – it's running out of memory, restarting, or can't keep up with requests because of an overloaded CPU.
- The database is slow and running at its limit – this could be a lack of computing resources, unoptimized queries or bad configuration.
- The database is running out of disk space – and without space, there's nothing to write to.
- A system function goes down – for example when the app suddenly stops sending SMS.
- Part of the system goes down – for example when the app loses access to data storage.
Monitoring tools
There are plenty of ways to watch an application these days. Sentry. Datadog. Logstash. New Relic. Prometheus. Snyk. Grafana… and I could go on.
This isn't about comparing or rating these tools, though. Each of them offers a certain service that may solve your problem. But here's an important thought too: it isn't always necessary to reach for a specialized tool if you can keep an eye on the thing with what you already have.
At Ackee we have experience with most of the tools mentioned above. Right now the closest to us is Sentry, but we don't primarily use even that for backend applications — mainly because it can only watch a running application. But what about application crashes? What about the other parts of the system that the app can't do without?
I'd call Prometheus and Grafana the industry standard. And yet — even that isn't our first choice. The reason? Cost. Not necessarily financial, but operational: setup, maintenance, integration… these aren't unmanageable things, but in the end they add further layers of complexity that often aren't essential.
Our setup
Ackee is a Google Cloud partner and we run our applications primarily on the Google Cloud (GCP) platform. When the need arises to watch a production application and ensure it keeps working, we try to make efficient use of the tools we already have for backend monitoring.
GCP itself offers ready-made monitoring dashboards for tracking the metrics of all the components I mentioned above – application servers, databases, load balancers, message queues and so on.
If we can watch an application, we should also set up alerting. GCP can do that too. Besides emails, it also offers integration with Slack, which we use at Ackee. When a metric crosses a configured threshold, GCP sends a message to Slack, where we handle it right away, without having to constantly stare at a dashboard.
Slack is where developers watch alerts every day and classify them by severity: critical errors, standard errors, errors that don't limit the system but are hard to solve, and misreported events or already-fixed problems.
Depending on the severity of the incident, it's linked to historical alerts and a ticket is created in our internal system with a proposed solution. For major errors, we consult the project team and sometimes the client to coordinate incident resolution.
Automatic alerts are great for a fast reaction. But they have their limits – they only kick in once a configured threshold is crossed. Slowly growing problems, though, are often visible only from the development of trends that an automated system still ignores.
That's why at Ackee we also do regular manual checks of the system. We go through the dashboards, compare how the metrics have developed and look for unusual behavior. An experienced developer's eye spots warning signs before the system does.
Every such check follows a clear checklist and we record the outputs. They serve as shared knowledge and a historical trail that comes in handy when tracing context after the fact.
Backend monitoring is just the beginning
For an application to run the way it should, having the right tools isn't enough – the developers' discipline is what's key. Monitoring and alerting can be handled by even a basic set of tools these days. Most teams can carve out the time to set them up, maintain them and deal with problems. But it's discipline that decides whether someone actually watches the alerts, whether we react to them in time, and whether we learn from incidents.
Discipline means:
- Reacting to errors before a user notices them
- Regularly checking the system, even when "everything's working" right now
- Keeping the system healthy over the long term, even when it's more tempting to write new code
Monitoring isn't a one-off affair, but a long-term commitment. When developers take it seriously, the application runs the way it should.
