When I joined a project as an external consultant, the first request I received was: "We want to improve our monitoring operations."

The service was already running. CloudWatch, logs, dashboards—everything was in place. Incidents only happened once every few months. The monitoring setup wasn't broken. But there was this vague feeling that things weren't being done "properly."

I started by understanding the current situation.

Issues That Emerged During Interviews

As I listened, various concerns came up:

All valid points. But the team also mentioned that the current business phase didn't justify heavy investment in monitoring. Development was the priority. That's a reasonable stance.

Then something caught my attention:

"Every morning, we spend about 30 minutes manually checking various screens."

Breaking Down the 30 Minutes

When I dug deeper, I found that most of those 30 minutes weren't spent thinking.

Open AWS console, navigate to a dashboard, change the time range, switch to another service, open the status page for an external API...

It was all navigation time—bouncing between scattered information sources.

The data was there. It was just spread across too many places.

This reframed the problem.

It wasn't "we need more monitoring." It was "checking our monitoring takes too much effort." Or more precisely: "Switching into operations mode every morning for 30 minutes is exhausting."

We concluded that improving the morning check process was the right direction.

But Is This Really the Right Approach?

After the interview, I paused to reflect.

Streamlining morning checks doesn't fix the "core" of monitoring. If alert design is weak, that problem remains. If external API monitoring is lacking, that problem remains too.

Is "morning check optimization" really what we should focus on now?

I decided to think it through.

What's the Purpose of Monitoring?

What is monitoring for?

At its core, I believe it's about "how quickly can we notice when users are affected?"

From this perspective, alert design and external API monitoring are about "detecting when something breaks." Morning checks, on the other hand, are about "maintaining a sense of normal." Different purposes.

flowchart TB
    A[Monitoring] --> B[Incident Response]
    A --> C[Routine Operations]
    B --> D[Alert Design<br>External API Monitoring]
    C --> E[Morning Checks]
    D --> F[Detect When Things Break]
    E --> G[Maintain Sense of Normal]

In the current phase where incidents are rare, alerts don't fire often. But if your sense of "normal" becomes dull, when an alert does fire, you won't be able to judge "is this actually serious?"

By looking at numbers every morning, you internalize the "typical patterns." That intuition is what enables you to spot anomalies.

Optimizing morning checks isn't "cutting corners." It's about making the practice sustainable while preserving that operational intuition.

The Direction for Optimization

So how do we optimize?

The 30 minutes were spent navigating between screens. We don't need to reduce what we look at—we need to reduce where we look.

In a previous project, I had set up a Jenkins job that generated a daily report and posted it to chat. Building the job was work, but once done, the routine became "just read what arrives."

The same approach could work here.

flowchart LR
    subgraph before[Current: Pull Model]
        direction TB
        P1[You] -->|check| P2[CloudWatch]
        P1 -->|check| P3[Logs]
        P1 -->|check| P4[External APIs]
        P1 -->|check| P5[Costs]
    end

    subgraph after[Target: Push Model]
        direction TB
        J[Jenkins Report] -->|delivered| M[You]
    end

    before -->|transform| after

Instead of going to dashboards (Pull), have summaries delivered to you (Push). Consolidate morning checks into "one deliverable."

Next Steps

The direction is clear. Now it's about execution. Here's the rough plan:

  1. Inventory current checks
    Document what you look at, where, and in what order

  2. Identify key daily metrics
    Don't include everything—start with the essentials

  3. Build a Jenkins job that posts to chat
    Keep it simple at first. Don't over-engineer

  4. Iterate while running
    Add what's missing, remove what's unnecessary

Aiming for perfection upfront will likely stall the project. Start small and iterate.

Current Thinking

Honestly, I don't know if this is the right answer.

But the direction—"optimizing morning checks"—feels reasonable.

Heavy investment in monitoring infrastructure doesn't make sense at this phase. But we don't want our operational intuition to fade. So we make the practice sustainable while preserving that intuition. That seems like a worthwhile effort.

For those who want to dive deeper into monitoring practices, I recommend this book:

[📦 商品リンク: moshimo-book-monitoring-intro]

And for those looking to systematically learn monitoring and infrastructure operations, there are specialized online schools for infrastructure engineers:

[📦 商品リンク: moshimo-sasaeru-banner-728x90]