liveBook · Manning

Monitoring

As explained in Think Like a Software Engineering Manager

Monitoring is the continuous observation and measurement of software systems and their operation to detect changes, failures, or performance issues.

When a service slows down or a change fails to take hold, monitoring turns vague concern into observable evidence. It continuously tracks system health, performance, or progress against agreed expectations so teams can detect problems, respond, and improve. section 12.2.5 section 13.2.5

Use monitoring to support several practical responsibilities:

  • Detect outages and performance issues early, then take proactive measures to reduce customer impact. section 12.2.5
  • Combine dashboards and alerts to expose service health, customer-use trends, abnormal values, and recovery toward expected ranges. section 12.2.5
  • Support troubleshooting by connecting observations with logs, run books, technical documentation, ownership, and root-cause analysis. section 12.2.5
  • Measure organizational change against predetermined success criteria, using feedback from surveys and retrospectives to find improvements. section 13.2.5
  • Track project-portfolio performance alongside resource allocation, risk management, prioritization, and decision support. section 10.1

From alert to recovery

A dashboard shows a service metric leaving its expected range. An alert points the team to relevant logs and a run book, which identifies ownership and guides mitigation. After the fix, the dashboard confirms that the service has returned to a healthy range. For a broader organizational change, surveys and retrospectives provide the equivalent feedback loop. section 12.2.5 section 13.2.5

Figure 12.1 Monitoring and dashboarding help provide visibility into the health of systems.
figure

A visual overview helps connect monitoring and dashboarding with visibility into overall system health. section 12.2.5

How Think Like a Software Engineering Manager covers it

How deep it goes
Explains monitoring through alerts, dashboards, logs, run books, success criteria, surveys, and retrospectives, without implementation details.
Examples
Uses service-health dashboards, outage alerts, logs, run books, surveys, retrospectives, and portfolio performance monitoring.
What it assumes
Assumes agreed expectations or success criteria, while introducing the visibility and feedback practices needed to assess them.
What you can do after
Diagnose and mitigate operational problems, verify recovery, and evaluate organizational changes against defined success criteria.
How it connects
Connects monitoring with logging, dashboards, alerting, run books, service-level agreements, root-cause analysis, and change management.

Also explained in

Compare how 40 books explain monitoring →

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Think Like a Software Engineering Manager. The section links point to the parts of the book it draws on.