Ask Your Dev Team about their monitoring and alerting
Your developer should know when something breaks before your customers do. Learn about uptime monitoring, error tracking, and why alerting is non-negotiable.
In issue 22, we talked about disaster recovery, what happens when things go seriously wrong. Monitoring is the early warning system that keeps most disasters from happening in the first place.
Your developer should have a way to know when something breaks. And they should know before you do. Definitely before your customers do.
Why this matters
Here’s a scenario that happens more often than it should: a customer emails you to say your app is down. You forward the email to your developer. They check and confirm it’s been down for two hours. Nobody noticed.
That’s two hours of lost revenue, lost trust, and a support headache that didn’t need to happen. An uptime monitor would have caught it in minutes.
You should never learn about an outage from your customers. That’s the bar. If your developer doesn’t have monitoring in place, they’re relying on luck.
Types of monitoring
There are several types, and a mature team will use more than one:
Uptime monitoring
The simplest and most critical. An uptime monitor checks whether your application is online at regular intervals. If it goes down, someone gets alerted immediately. This can be the difference between a two-minute blip and a two-hour outage.
Error tracking
Your application will throw errors. Some are harmless. Some mean something is broken for a subset of users. Error tracking tools capture these in real time, grouping similar errors together and showing how many users are affected.
Without error tracking, bugs hide. Users experience problems, get frustrated, and leave. Your developer never knows unless someone complains.
Performance monitoring
Your app might be online but running slowly. Pages that take ten seconds to load, API calls that time out, database queries that choke under load. Performance monitoring tracks response times and resource usage so your developer can spot bottlenecks before they become outages.
Log management
Logs are the detailed record of everything your application does. When something goes wrong, logs are how your developer figures out what happened and why. Good log management means those records are searchable, organized, and retained long enough to be useful.
What to ask
“What monitoring do you have in place, and who gets alerted?” You want to know that alerts go to real people who can act on them. An alert that goes to an unmonitored inbox is the same as no alert.
“How quickly would you know if the application went down?” The answer should be minutes, not hours.
“Can I have access to the monitoring dashboard?” This isn’t a requirement, but if you want visibility, a good developer will make that possible. Some clients want to see uptime stats and error rates. Others are happy with a summary in their regular check-in. Either way, the option should be there.
“What’s your process when an alert fires?” There should be a defined response. Who investigates? How quickly? How do they communicate the issue and resolution to you?
At minimum
Not every project needs the full suite from day one. But at a bare minimum, your developer should have uptime monitoring and error tracking in place before your product goes live. These two alone cover the most common and most damaging failure modes.
If your developer tells you they’ll “set up monitoring later” or “keep an eye on things manually,” push back. Manual monitoring means no monitoring. Things break at 2 AM on a Saturday, not during business hours when someone is watching.
Expect better. Build better.