Low‑Cost Exception Monitoring Strategies for Startup Teams

Introduction

A few days ago a reader told me he was scolded by his product manager because a bug appeared in production and was only discovered through customer feedback.

I asked him whether they had any monitoring in place.

The reader replied that their newly founded startup focuses on delivering features and has no time to build basic infrastructure.

As the saying goes, use a solution that fits the size of your "bowl"; you don’t need an overly complex system—just a small, sufficient monitoring setup that can solve the problem.

Below are some common exception‑monitoring approaches.

Minimal Cost

For a brand‑new startup, you can achieve real‑time exception monitoring with the lowest implementation cost, meaning you don’t rely on any third‑party frameworks.

Manual instrumentation can be used to trigger alerts, preferably placed in a global exception handler so that all errors are managed centrally.

Example code:

@ExceptionHandler(value = Exception.class)
@ResponseBody
public ResponseData<Object> defaultErrorHandler(HttpServletRequest req, Exception e) {
   // record the exception
   // send DingTalk or SMS alert
}

When a global exception handler catches an error, you can obtain request details from HttpServletRequest and send an alert.

Exception Alert Information

Alert messages must be detailed; without sufficient information the problem cannot be reproduced or diagnosed.

An alert should contain at least the following fields:

Alert Service: mobile-gateway
Owner: yinjihuan
Request URL: http://xxx.com/xxx/xxx?id=xxx
Request Body: { "name": "xxx" }
Request Header: key=value
Error Code: 500
Error Type: RuntimeException
Stack Trace: java.lang.RuntimeException: com.xxx.exception.ApplicationException: Failed to get XXX info!

The request parameters are the most critical part for reproducing the error. Note that reading the request body directly from HttpServletRequest can only be done once, so you need to cache it, for example by decorating the request with ContentCachingRequestWrapper .

Minimal Cost with Performance Consideration

Sending alerts synchronously from the exception handler adds a slight latency, but since the request has already failed, the impact is minimal.

You can improve this by making the alert asynchronous—e.g., pushing it to a thread pool or an in‑memory queue processed by a separate thread.

If you want to avoid losing alerts, use an external message queue and a dedicated consumer to handle the alerts.

Unified Log Monitoring

The minimal‑cost approach only requires a few dozen lines of code, but the alert logic becomes coupled with each project.

Using a centralized log platform (EFK/ELK) allows you to write exception details to local logs and let a separate alerting system decide when to notify based on log patterns.

Both open‑source and commercial log solutions exist; commercial cloud services are easy to set up but incur costs.

For pure exception monitoring, the open‑source error‑tracking system Sentry is recommended; it provides real‑time error tracking and also offers a commercial version.

APM Monitoring

Application Performance Management (APM) tools not only trace service call chains and performance metrics but also monitor exception information.

Common APM solutions include SkyWalking, Pinpoint, and CAT. Using CAT as an example, its problem report page lists application errors, and the dashboard highlights error spikes in red.

CAT also supports alerting, which is essential because manual dashboard checks are impractical.

For a deeper dive into CAT, see the linked article: https://mp.weixin.qq.com/s/3mqmySr2nv4Xpd6nZlfsVg

Conclusion

Implementing a minimal‑cost exception monitoring solution can be done in roughly a day. If you don’t set up monitoring, you’ll keep getting scolded. Bugs are inevitable; the goal is to detect and eliminate them as soon as they appear.