IT Monitoring & Alerting Guide: Uptime, Services, Processes, and HTTP Checks (Complete Guide)

Monitoring isn’t “more alerts.” It’s a system for answering one question quickly:

Is something broken right now—and what should we do next?

This guide shows how to build a monitoring and alerting approach that produces signal (not noise), speeds triage, and prevents repeat incidents.

Answer first (for busy ops)

IT monitoring is continuous measurement of endpoint and service health. Alerting is routing only actionable changes to the right person, with the right severity.

Quick steps

1. Monitor the “4 basics”: uptime/reachability, services, processes, and critical endpoints (HTTP)
2. Use device-centric internal monitors for on-box checks (services/process/local HTTP)
3. Use external HTTP monitors for public endpoints
4. Route alerts by severity to reduce fatigue
5. Always include: what changed, when it started, and where to look next
6. Add a “verification loop” (monitor confirms recovery after actions)

Key takeaways

• Alerting should be actionable: if no one should act, don’t alert.
• The fastest triage comes from history (what happened when) + context (what likely caused it).
• Your monitors should support the same workflow: detect → act → verify.

Table of contents

• What to monitor first (the minimum set)
• Internal vs external monitoring (when to use each)
• Building alerts that don’t burn teams out
• Triage workflows (what to do when something goes red)
• Common failure modes and what they mean
• Glossary
• FAQ

What to monitor first (the minimum set)

If you’re starting from scratch, don’t try to monitor everything. Start with what breaks frequently and causes downtime:

1. Reachability / last seen (is the endpoint actually reporting?)
2. Critical Windows services (service down = functionality down)
3. Core processes (agents and business processes disappearing)
4. Critical endpoints (HTTP) (public portals/APIs)
5. Disk pressure (disks filling up cause cascading failures)
6. Early failure signals (SMART, logs, recurring warnings)

Telmetra’s “Computer Details” + “Live Monitoring” are designed to make this minimum set fast to work with:

• Faster Endpoint Triage with Telmetra Computer Details
• Telmetra Live Monitoring: Endpoint Activity and Internal Health Checks

Internal vs external monitoring (when to use each)

Internal monitors (device-centric checks)

Internal monitors answer: “Is this specific computer healthy?”

Use internal monitors for:

• Windows services
• Windows processes
• internal/local HTTP endpoints

They’re ideal for root cause confirmation and verification after action.

Reference:

• Telmetra Live Monitoring: Internal Monitors

External HTTP monitors (public endpoints)

External monitors answer: “Is this public endpoint reachable from outside?”

Use them for:

• customer portals
• public APIs
• externally reachable websites

Reference:

• External HTTP Monitoring in Telmetra

Building alerts that don’t burn teams out

Most monitoring programs fail because they generate noise. Fix alerting before you add more monitors.

1) Route by severity

Make “Critical” rare and meaningful. Everything else should be informational or grouped.

Telmetra supports severity-based email routing:

• Telmetra Email Notifications: Fine-Tune Alerts by Severity

2) Alert on state changes, not on “still broken”

Alerts should represent changes:

• Up → Down
• Down → Up
• Healthy → Degraded

3) Prefer “actionable” thresholds

Instead of “CPU is 65%,” alert on conditions that require action:

• sustained high CPU for N minutes
• repeated failures
• disk trend indicates “will fill within X days”

4) Include next steps in the alert (or link to a runbook)

Your alert should answer:

• What broke?
• When did it start?
• Where do I look?
• What is the first safe action?

Triage workflows (what to do when something goes red)

Service is down

Workflow:

1. Confirm the monitor is a service monitor
2. Restart the service
3. Verify recovery on the next monitor check

Reference:

• Restart Windows Services Directly from Live Monitoring

Endpoint is “slow” or unstable

Workflow:

1. Confirm last seen is fresh
2. Check the health snapshot (CPU/RAM/disk/network)
3. Review recent changes (reboots/updates/events)
4. Only then start a session if needed

Reference:

• Computer Details: fast triage workflow

Disk is filling up

Workflow:

1. Identify the folder/segment that grows
2. Review size history to find when it started
3. Set an alarm to prevent repeats

Reference:

• Files and Folders Growth Monitoring

“We got hit by a wave of failures”

First action is often to reduce noise:

1. Ensure routing is “Critical only” to inbox for responders
2. Confirm whether it’s one site, one client, or many endpoints
3. Use history views and timestamps to cluster incidents

Common failure modes and what they mean

External HTTP monitor failures

• DNS failures: name resolution problems, misconfigured DNS, ISP issues
• TLS errors: expired certs, misconfigured chain, SNI mismatch
• 5xx responses: app/server errors; correlate with deployments
• timeouts: upstream routing, WAF, DDoS mitigation, backend overload

Reference:

• External HTTP Monitoring in Telmetra

Early warning signals (before outages)

Good monitoring catches signals before users complain:

• SMART degradation
• repeating disk warnings
• event log patterns

Reference:

• Early Computer Failure Detection with SMART, Logs, and Alerts

Glossary

• Alert fatigue: excessive non-actionable alerts leading to missed critical events
• SLO/SLA: service reliability targets; monitoring validates whether you’re meeting them
• MTTA/MTTR: mean time to acknowledge / recover; monitoring reduces both when done right
• Internal monitor: per-device health check (service/process/internal HTTP)
• External monitor: outside-in uptime check (public HTTP)

FAQ

What’s the first monitor I should add for Windows endpoints?

Start with critical services and the checks that confirm your most common incidents (service down, process missing, disk growth).

How do I stop getting spammed by alerts?

Route by severity, alert on state changes, and remove informational alerts from inbox delivery.

Next step: turn incidents into monitors

Every time you fix the same issue twice, add a monitor and a simple runbook link. That’s how monitoring becomes a multiplier instead of a cost.