Continuous Monitoring | NOC.org Support

NOC Continuous Monitoring tracks the availability and performance of your websites and APIs around the clock. Checks run from multiple geographic locations at regular intervals, and alerts are sent immediately when downtime or performance degradation is detected.

How Monitoring Works

Continuous monitoring sends automated requests to your configured endpoints at regular intervals. Each check verifies that your site or API responds correctly within expected time thresholds. If a check fails, NOC confirms the issue from additional monitoring locations before triggering an alert. This multi-location verification prevents false positives caused by temporary network issues at a single location.

Monitoring runs independently of the CDN and WAF layers. Even if your site is proxied through the NOC CDN, monitoring checks can be configured to test both the CDN endpoint and your origin server directly, giving you visibility into both layers.

Check Types

NOC supports several monitoring check types to cover different use cases:

• HTTP/HTTPS: Send a GET or HEAD request to a URL and verify the response status code (e.g., 200 OK). You can also verify that the response body contains or excludes specific text strings, which catches scenarios where a server returns 200 but displays an error page.
• TCP: Verify that a specific port is open and accepting connections. Useful for monitoring databases, mail servers, or custom services.
• DNS: Query a DNS record and verify the expected response. Detects DNS resolution failures or unexpected record changes.
• Ping (ICMP): Basic connectivity check to verify that a host is reachable on the network.

Multi-Location Monitoring

Checks are performed from monitoring nodes distributed across multiple geographic regions. This provides several advantages:

• Global perspective: Detect issues that affect visitors in specific regions, such as localized network outages or CDN PoP failures.
• False positive reduction: A single failed check from one location does not immediately trigger an alert. NOC confirms the failure from additional locations before sending notifications, reducing noise from transient network blips.
• Latency baselines: Monitoring from multiple locations establishes latency baselines for different regions, making it easier to identify performance regressions that affect specific geographies.

Check Intervals

You can configure how frequently monitoring checks run:

• 1-minute intervals: For critical production systems where every minute of downtime matters.
• 5-minute intervals: A balanced option for most websites and APIs.
• 15-minute or 30-minute intervals: For lower-priority systems or staging environments.

Shorter intervals detect outages faster but generate more monitoring traffic. For most production websites, 1-minute or 5-minute intervals provide the best balance between detection speed and resource usage.

Alert Channels

When an outage or performance issue is confirmed, NOC sends alerts through your configured notification channels:

• Email: Send alert notifications to one or more email addresses. Includes downtime details, affected endpoint, and check results.
• Slack: Post alerts to a Slack channel via incoming webhook integration. Ideal for teams that use Slack for operations communication.
• Webhooks: Send alert data as a JSON payload to any HTTP endpoint. Use this to integrate with PagerDuty, Opsgenie, custom dashboards, or incident management tools.
• SMS: Receive text message alerts for critical notifications (available on supported plans).

You can configure different alert channels for different severity levels. For example, send email alerts for warning-level issues and SMS plus Slack alerts for critical outages.

Uptime Reporting

NOC maintains a historical record of all monitoring checks, providing:

• Uptime percentage: View your site's uptime over 24 hours, 7 days, 30 days, or custom date ranges.
• Response time graphs: Track response time trends to identify gradual performance degradation before it becomes an outage.
• Incident history: Review past downtime events including start time, duration, affected locations, and resolution time.
• Status pages: Share uptime status with your users through a public or private status page.

Best Practices

• Monitor both CDN and origin: Set up separate checks for your CDN-fronted URL and your origin server IP to identify whether issues are at the edge or the origin.
• Use content verification: For HTTP checks, verify response body content (not just status codes) to catch "soft failures" where the server returns 200 but displays an error message.
• Set appropriate thresholds: Configure response time thresholds based on your baseline performance. Alert when response times exceed your normal range, not just when the site is completely down.
• Route alerts to the right team: Use webhook integrations to route alerts into your incident management workflow so the right people are notified immediately.