top of page

URL EndPoint Monitoring Policy 

 

1. Purpose

​

As part of the Habitat3 CloudOps Service, Habitat3 monitors nominated customer website and web application URLs. The number of production endpoints included in the Habitat3 CloudOps Service depends on the tier.

 

CloudOps Essentials - 10 included - $11 inc GST per additional per month

CloudOps Standard - 20 included - $11 inc GST per additional per month

Cloudops Professional - 30 included - $11 inc GST per additional per month

 

URL monitoring is intended to identify potential service availability issues and help determine whether an outage has been caused by AWS infrastructure managed by Habitat3.

​

Once an alerts is received by Habitat3 we will commence investigation. All investigation and remediation work will utilise monthly engineering hours.

 

2. Standard URL monitoring

Habitat3 will configure a standard availability monitor for each nominated production URL.

The standard monitor will:

  • Check the nominated URL once every minute;

  • Confirm that the URL resolves and returns the expected HTTP response;

  • Generate an alert after 30 consecutive failed checks, confirming that the URL has remained unavailable for 30 minutes;

  • Send the alert to Habitat3 and the customer’s nominated contacts; and

  • Send a recovery notification when a subsequent check confirms that the URL is available again.

 

Where supported by the monitoring platform, Habitat3 may validate an outage from more than one monitoring location to reduce false alarms caused by temporary internet or monitoring-provider issues.

 

3. Additional customer alerts

Customers may request a separate, shorter-interval alert (for example, 1, 5, 10 or 15 minutes), configured as an additional monitor against the same URL and sent directly to the customer's own nominated contacts.

Customers may also request the following additional monitoring conditions, all natively supported:

  • Unexpected HTTP response code;

  • SSL/TLS certificate approaching expiry; or

  • Failure to return nominated website content.

 

Unless otherwise agreed in writing, Habitat3 will not receive, investigate or respond to these additional alerts. Habitat3's investigation process commences when the standard 30-minute alert is generated.

 

4. Monitoring and response coverage

URL monitoring operates continuously. However, Habitat3’s response to an alert depends on the CloudOps coverage selected by the customer.

​

Standard CloudOps coverage

Habitat3 will investigate standard 30-minute URL alerts received during the service hours defined in the customer’s CloudOps agreement.

Alerts generated outside the customer’s service hours will continue to be sent to the customer. Habitat3 will commence its investigation when the next service period begins.

​

5. Initial alert validation

When Habitat3 receives a standard URL availability alert during the customer’s applicable coverage period, Habitat3 will:

  1. Confirm that the alert remains active.

  2. Attempt to access the affected URL independently.

  3. Record the response code, error message, response time and observed behaviour.

  4. Confirm whether the domain resolves and whether a valid HTTPS connection can be established.

  5. Check whether the failure is occurring from more than one monitoring location, where this information is available.

  6. Review any current or recently completed planned maintenance.

 

If the URL has already recovered, Habitat3 will review the available monitoring information and advise the customer that a temporary availability event occurred.

​

6. AWS infrastructure investigation

If the URL remains unavailable, Habitat3 will investigate the relevant AWS infrastructure included within the customer’s CloudOps scope.

 

The investigation may include the following checks, depending on the customer’s architecture.

AWS service health

  • Check for known AWS service incidents;

  • Check for regional or Availability Zone disruptions; and

  • Review relevant AWS Health notifications.

DNS and Route 53

  • Confirm that the domain resolves correctly;

  • Review relevant Route 53 hosted-zone records;

  • Confirm that alias and routing targets are correct;

  • Review Route 53 health checks, where configured; and

  • Identify any recent DNS configuration changes.

CloudFront (if in use)

  • Confirm that the CloudFront distribution is enabled;

  • Review origin connectivity;

  • Review HTTP 4xx and 5xx error rates;

  • Check for certificate or domain-name configuration issues; and

  • Review applicable CloudFront or edge-function errors.

AWS WAF (if in use)

  • Confirm that the relevant Web ACL is available and correctly associated;

  • Review whether legitimate requests are being blocked; 

  • Check for recent Web ACL or rule changes; and

  • Review elevated blocked-request activity.

Application Load Balancer (if in use)

  • Confirm that the load balancer and listeners are operational;

  • Review listener rules and routing configuration;

  • Review target-group health;

  • Identify unhealthy or unavailable targets;

  • Review load-balancer and target HTTP errors; and

  • Check for recent configuration changes.

Compute services

Where applicable, Habitat3 will review:

  • EC2 instance and system status checks;

  • Auto Scaling Group capacity and scaling events;

  • ECS service and task health;

  • EKS cluster and workload health;

  • Lambda errors, throttling and invocation failures; and

  • Other AWS compute services supporting the application.

Network connectivity

Where relevant, Habitat3 will review:

  • VPC routing;

  • Security groups;

  • Network ACLs;

  • NAT gateways;

  • Internet gateways;

  • AWS network connectivity; and

  • Recent network configuration changes.

Supporting AWS services

Where they form part of the monitored environment, Habitat3 may also review:

  • RDS database availability;

  • ElastiCache availability;

  • S3 availability and permissions;

  • Storage capacity;

  • Queues and messaging services;

  • API Gateway;

  • Authentication services; and

  • Other AWS-managed dependencies required by the application.

Monitoring and recent changes

Habitat3 will also review, where available:

  • Relevant CloudWatch alarms, metrics and logs;

  • Infrastructure deployments;

  • Configuration changes;

  • Scaling events;

  • Resource failures; and

  • Other recent events that correspond with the outage.
     

7. AWS infrastructure issue identified

If Habitat3 identifies an issue involving AWS infrastructure managed under the CloudOps Service, Habitat3 will:

  • Notify the customer by email that an AWS infrastructure issue has been identified;

  • Explain the issue and its likely impact, where known;

  • Troubleshoot the affected AWS service;

  • Take reasonable and authorised steps to restore functionality;

  • Keep the customer informed of material developments; and

  • Notify the customer by email when the AWS infrastructure has been restored or stabilised.

 

Habitat3 will also confirm whether the monitored URL has recovered.

If remediation requires customer approval, application changes, third-party involvement or work outside the agreed CloudOps scope, Habitat3 will advise the customer and request further instructions.

 

Habitat3 cannot guarantee the timeframe for resolving an incident caused by an AWS service or regional outage outside Habitat3’s direct control.

​

8. No AWS infrastructure issue identified

If Habitat3’s investigation indicates that the AWS infrastructure managed under the CloudOps Service is functioning as expected, Habitat3 will advise the customer by email.

​

The customer will then be responsible for investigating potential issues involving:

  • Application code;

  • Application configuration;

  • Content management systems;

  • Application-level database configuration;

  • Software deployments;

  • External DNS or domain-registration services;

  • Authentication providers;

  • Third-party APIs and integrations; or

  • Other services outside Habitat3’s CloudOps scope.

 

Habitat3 may assist with further investigation if requested.

​

9. Incident communications

Habitat3’s initial incident email will include, where available:

  • The affected URL;

  • The time the standard alert was generated;

  • Whether the URL remains unavailable;

  • The investigation status;

  • Any AWS infrastructure issue identified; and

  • The next action required from Habitat3 or the customer.
     

Habitat3 will provide further updates when:

  • A material cause is identified;

  • Customer approval or assistance is required;

  • The incident is handed to another service provider;

  • AWS infrastructure functionality is restored; or

  • The investigation determines that the AWS infrastructure is functioning as expected.
     

A final recovery or investigation outcome notification will be sent to the customer.

​

10. Planned maintenance

Customers must advise Habitat3 in advance of planned application, website, DNS or infrastructure maintenance that may cause a monitored URL to become unavailable.

Where advance notice is provided, Habitat3 may establish a maintenance window and temporarily suppress operational alerts.

​

URL checks may continue during the maintenance window for reporting purposes, but Habitat3 will not investigate expected availability alerts unless specifically requested by the customer.

If maintenance continues beyond the agreed maintenance window, standard monitoring and response arrangements will resume.

Customers may also request an automated maintenance-mode integration linked to their CI/CD pipeline, so that alerts are automatically suppressed for the duration of a deployment. Where configured, this removes the need for the customer to manually notify Habitat3 of each individual deployment-related maintenance window.

​

11. Customer responsibilities

The customer is responsible for:

  • Providing the correct production URLs to be monitored;

  • Nominating the contacts who should receive alerts;

  • Advising Habitat3 when URLs should be added, changed or removed;

  • Advising Habitat3 of relevant DNS, architecture or application changes;

  • Providing notice of planned maintenance, or configuring the CI/CD maintenance-mode integration where applicable;

  • Maintaining appropriate application development and support arrangements;

  • Ensuring Habitat3 has the access required to investigate the AWS environment; and

  • Maintaining current escalation contacts for application developers and other service providers.
     

12. Monitoring limitations

Standard URL monitoring confirms whether a nominated endpoint resolves, accepts a connection and returns the expected HTTP response.

​

Unless specifically configured and agreed, URL monitoring does not confirm that:

  • Every page or application function is operating correctly;

  • Users in every location can access the service;

  • User authentication is functioning;

  • Transactions can be completed successfully;

  • Application data is accurate;

  • Third-party integrations are functioning;

  • The application is free from performance degradation; or

  • Every short or intermittent outage will generate a Habitat3 alert.

 

URL monitoring and alerting do not constitute a guarantee of continuous website or application availability.

​

Date Last Updated: 11 August 2026

bottom of page