Define done

Minimum viable monitoring is complete when:

  • an outside check confirms the application is reachable;
  • one critical user workflow is tested end to end;
  • server errors are captured with a request or correlation identifier;
  • scheduled or queued work reports success and failure;
  • resource exhaustion has a visible threshold; and
  • one named responder has received a test alert.

Google's monitoring guidance organizes signals around latency, traffic, errors, and saturation. A small app does not need Google's scale, but it benefits from distinguishing symptoms users feel from internal causes. The OpenTelemetry observability primer also separates traces, metrics, and logs; installing a telemetry library is not the outcome unless the resulting evidence answers an operating question.

Step 1: write the critical-workflow sentence

Use one sentence:

Every five minutes, a test identity can sign in, load the request list, and receive a valid response without changing production data.

Choose a safe workflow representing real dependencies. A homepage check cannot detect a broken database, identity provider, or API. Avoid a synthetic test that sends customer email, creates invoices, or otherwise causes a real business effect.

Step 2: add five signals

  1. Reachability: request a health endpoint from outside the hosting environment.
  2. Workflow: exercise the safe critical path and verify its result.
  3. Errors: capture unhandled server failures with time, revision, route, environment, and correlation ID.
  4. Background work: emit a heartbeat for each required job and alert on a missed completion window.
  5. Saturation: watch the resource most likely to stop useful work, such as database connections, storage, memory, or a provider quota.

Do not log passwords, tokens, uploaded document contents, or unnecessary personal data.

Step 3: route actionable alerts

Every alert needs:

  • a plain-language failure;
  • affected environment and workflow;
  • first check to perform;
  • dashboard or log link;
  • safe rollback or containment option;
  • named primary and backup owner; and
  • escalation timing.

Send a deliberate test failure. Confirm the responder receives it, can find the evidence, and knows whether to repair, roll back, disable a feature, or contact a provider.

Step 4: review one monitoring card

Keep this compact record:

Signal Check interval Failure threshold Owner Last tested
Reachability
Critical workflow
Server errors
Background job
Saturation

Review it weekly at first. Remove alerts that cannot produce an action, and fix noisy thresholds rather than training people to ignore them.

Verify the setup

  • Break the safe test dependency and observe the alert.
  • Confirm the message identifies the environment and workflow.
  • Follow the linked evidence from a device the responder will actually use.
  • Record detection time and response decision.
  • Restore the dependency and verify the alert clears.

This setup does not make an application reliable or secure. It creates the smallest inspectable feedback loop from failure to accountable response.