Why Uptime Matters for Paid Advertising and How to Monitor It on Alibaba Cloud

Learn how website downtime impacts paid advertising budgets and how to monitor landing page uptime using Alibaba Cloud CloudMonitor, SLB, and Log Serv...

Paid advertising has a simple cost model. You pay when someone clicks, and the click only has value if the page behind it loads. When the landing page is down, slow, or returning errors, the ad platform still charges for the click. The visitor leaves, and the budget is gone.

Most teams spend hours on keywords, bids, and ad copy, then give very little thought to whether the destination stays online during the campaign. Infrastructure problems tend to show up at the worst moments: launch day, a sale, or a weekend when nobody is watching the dashboards.

This guide explains how downtime affects paid campaigns and how to build a monitoring setup on Alibaba Cloud that catches problems within minutes. You will set up external availability checks with CloudMonitor, add health checks at the load balancer, route alerts to the right people, and make the page itself harder to knock offline.

By the end, you will have:

A clear way to measure what downtime costs your campaigns
A layered monitoring design using CloudMonitor, Server Load Balancer, and Log Service
Step-by-step instructions for creating site monitoring tasks, with a command-line example
An alert policy that avoids both silence and noise
A pre-launch checklist you can reuse for every campaign

What downtime does to a paid campaign

Downtime hurts paid traffic in more ways than lost clicks. It helps to separate the effects.

Direct wasted spend. Every click that lands on an error page costs money and produces nothing. If a campaign spends $500 per day, that is roughly $21 per hour. A three-hour outage during peak traffic can cost far more than that average, because spend usually concentrates around the times your audience is most active.

Disapproved ads. Ad platforms check where your ads point. Google Ads, for example, has a destination policy that can disapprove ads when the landing page does not work. A short outage at the wrong moment can pause ads that then need to be reviewed and re-approved, which extends the damage well past the outage itself.

Weaker landing page quality signals. Platforms score landing page experience as part of ad quality. A page that fails or responds slowly repeatedly gives you worse signals over time, which can raise the cost of each click.

Distorted conversion data. Automated bidding strategies learn from conversions. If a page is down for several hours, conversions drop to zero for reasons that have nothing to do with ad quality. The bidding system may read this as a performance problem and adjust in the wrong direction.

Lost trust. A visitor who clicks an ad and sees a timeout is unlikely to come back through a second click.

The common thread is that downtime costs more than the minutes it lasts. That is the case for treating availability as part of campaign management.

Putting numbers on availability

Availability is usually quoted as a percentage. The percentages sound close together, but the allowed downtime differs a lot.

Availability target	Allowed downtime per 30-day month
99%	About 7.2 hours
99.9%	About 43 minutes
99.95%	About 22 minutes
99.99%	About 4.3 minutes

A landing page that hits 99% sounds healthy, yet it can be offline for more than seven hours a month. If those hours land on a campaign launch, the average does not help you.

For a quick estimate of what an outage costs, use this formula:

Wasted spend = hourly ad spend x outage hours x share of traffic that reached the broken page

For example, a campaign spending $40 per hour with a two-hour outage that affected all traffic wastes about $80 in clicks. That figure excludes the lost conversions, which are usually worth several times the click cost. Run this calculation against your own numbers. It gives you a concrete way to decide how much redundancy and monitoring effort is reasonable.

What "down" actually looks like

A complete outage is the easiest failure to spot. Most damaging problems are quieter. Before designing monitoring, list the ways a landing page can fail.

Failure mode	What the visitor sees	Why simple checks miss it
Server or instance stopped	Connection refused or timeout	Easy to catch with a ping or HTTP check
Application error	HTTP 500 or 502 page	A ping still succeeds because the server responds
Slow response	Page hangs, visitor leaves	The page technically loads, so no alarm fires
Expired TLS certificate	Browser security warning	The server is healthy, but visitors cannot proceed
DNS problem	Site not found	Checks from inside your network may still work
Wrong or empty content	Blank page or fallback template	Status code is 200, so a status-only check passes
Regional problem	Fails for one country or network	Checks from a single location look fine

This table drives the design in the next section. A ping check covers the first row. The others need checks that look at status codes, response time, page content, certificates, DNS, and multiple locations.

A layered monitoring design on Alibaba Cloud

No single tool covers all of those failure modes, so use layers. Each layer answers a different question.

Layer 1: External checks      "Can a visitor reach the page right now?"
          CloudMonitor Site Monitoring

Layer 2: Load balancer checks "Is each backend server healthy?"
          Server Load Balancer health checks

Layer 3: Host metrics         "Is the server running out of resources?"
          CloudMonitor ECS metrics

Layer 4: Logs                 "What went wrong, and when did it start?"
          Log Service

Layer 5: Alerts and routing   "Who finds out, and how fast?"
          CloudMonitor alert rules and contact groups

Layer 1 tells you that something is wrong from the visitor's point of view. Layers 2 to 4 tell you why. Layer 5 gets the right person looking at it quickly.

If you already track campaign infrastructure health, the earlier guide on Monitoring Marketing Campaign Infrastructure with Alibaba Cloud CloudMonitor covers the host-level side in more detail. This article focuses on the visitor-facing checks that matter most for paid traffic.

Step 1: Create external availability checks with CloudMonitor

CloudMonitor Site Monitoring sends requests to your URL from detection points outside your own servers. That outside view is the closest you can get to what a real visitor experiences.

Site monitoring supports several protocols, including HTTP(S), PING, TCP, UDP, DNS, SMTP, POP3, FTP, and WebSocket. For a landing page, HTTP(S) is the main one. You can pick PC, mobile, or VPC detection points depending on where you want the probes to run.

Create the task in the console

Open the CloudMonitor console and go to the site monitoring section.
Create a new task and choose the HTTP(S) protocol.
Enter the exact landing page URL, including the path and any query string your ads use. Monitor the real destination, not just the home page.
Set the request method to GET.
Choose the detection interval. The default is one minute, and the supported values are 1, 5, 15, 30, and 60 minutes. Use one minute during active campaigns.
Add response checks, covered in the next section.
Attach an alert rule and a contact group, then save the task.

Menu names change between console versions, so follow the labels you see in your console and use the steps above as the outline.

Choose checks that catch quiet failures

A status code check alone misses blank pages and wrong content. Combine three checks:

Status code. Alert when the response is anything other than 200 (or 301/302 if your ad URLs redirect on purpose).
Response time. Alert when the time exceeds a threshold that matches your performance goals. A page that takes eight seconds to respond is down for practical purposes.
Response content. Check that the response contains a string that only appears when the page renders correctly, such as the main call-to-action text or a form element name. This catches fallback pages and empty templates that still return 200.

The content check matters most for paid campaigns. A maintenance page or a failed deployment often returns a perfectly healthy status code.

Create the same task from the command line

If you manage several landing pages, scripting the task creation saves time and keeps settings consistent. This example uses the Alibaba Cloud CLI with the CreateSiteMonitor API. Check parameter names against the current CloudMonitor API reference before you run it, because options can change.

aliyun cms CreateSiteMonitor \
  --TaskName "landing_page_uptime" \
  --TaskType HTTP \
  --Address "https://www.example.com/spring-offer" \
  --Interval 1 \
  --OptionsJson '{
    "http_method": "GET",
    "time_out": 5000,
    "match_rule": 1,
    "response_content": "Book your free call"
  }'

In this example:

Interval of 1 runs the check every minute.
time_out of 5000 treats a request as failed after five seconds.
match_rule set to 1 means the check passes only if the response contains the response_content text.

Replace the URL and the text string with values from your own page, and give each landing page its own task name so alerts are easy to read.

Monitor more than one URL

Do not stop at the landing page. A paid campaign depends on a short chain, and any link in it can fail:

The landing page URL used in the ads
The form submission endpoint or checkout step
The thank-you or confirmation page
The domain's DNS resolution

Create a separate task for each, and name them in order so the alert tells you which step broke.

Step 2: Add health checks at the load balancer

External checks tell you the visitor-facing result. If you run more than one backend server behind a Server Load Balancer (SLB), health checks tell you which server is failing, and they stop traffic from reaching it.

Configure a health check on each listener. Point it at a lightweight path on the application, not the home page, so a heavy page render does not skew results.

Add a health endpoint

Here is a minimal health endpoint for an Nginx-served application:

location = /healthz {
    access_log off;
    default_type text/plain;
    return 200 "ok";
}

This returns 200 whenever Nginx is running. It proves the web server is alive, but it will not notice a broken application behind it. For dynamic sites, make the endpoint call the application and check its dependencies, such as the database connection:

# Example Flask health endpoint
from flask import Flask, jsonify

app = Flask(__name__)

@app.route("/healthz")
def healthz():
    try:
        db_ok = check_database_connection()   # your own function
    except Exception:
        db_ok = False

    status = 200 if db_ok else 503
    return jsonify({"database": db_ok}), status

A shallow check catches a stopped web server. A deeper check catches a healthy web server in front of a failing database. Use the deeper version for the SLB, and keep it fast, because the load balancer calls it frequently.

Tune the thresholds

Health check settings control how quickly a bad server is removed and how quickly a recovered one comes back. Two settings matter most:

Unhealthy threshold. The number of failed checks before a backend is marked unhealthy. A low number removes bad servers faster but can react to one-off blips.
Healthy threshold. The number of successful checks before a server returns to rotation. A higher number avoids putting a half-recovered server back under load.

Start with moderate values, then adjust after you watch real behavior during a test.

Step 3: Watch the host metrics

When an external check fails, you need to know whether the cause is resource exhaustion. The CloudMonitor agent reports metrics from your Elastic Compute Service (ECS) instances. For a landing page server, watch:

CPU utilization
Memory utilization
Disk usage
Network bandwidth and connection counts

Set alerts on warning levels, not only on failure. For example, an alert at 80% CPU gives you time to scale before the page slows down, while an alert at 100% arrives after the damage.

Pair these with Auto Scaling where it fits. If traffic from a new campaign pushes CPU past a threshold, scaling rules can add instances to the SLB backend pool automatically. Scaling policies also help when a health check removes an unhealthy instance, because the group can replace it.

Step 4: Keep logs for diagnosis

Alerts tell you that something broke. Logs tell you why. Ship web server and application logs to Log Service so you can search them during an incident.

The most useful queries during an outage are the simplest ones:

How many 5xx responses per minute over the last hour?
Which URLs are returning errors?
When did the error rate first rise?
Did response times climb before the errors started?

That last question often reveals a slow build-up, such as a memory leak or an exhausted connection pool, and you can use it to fix the cause instead of only restarting the server. The guide on Building a Content Performance Tracking System with Alibaba Cloud Log Service shows how to set up Log Service dashboards that you can adapt for error tracking.

Keep your logging focused on operational data such as status codes, response times, and request paths. You do not need personal visitor details to diagnose availability problems.

Step 5: Design alerts people will act on

A monitoring setup fails if nobody responds to its alerts. Two problems cause that: alerts that arrive too late, and alerts that arrive so often that people ignore them.

Reduce false alarms

A single failed probe can come from a brief network issue between the detection point and your server. Configure the alert rule to require several consecutive failures before it fires. The CloudMonitor alert rules include a retry count, which handles this. Two or three consecutive failures at a one-minute interval keeps detection under five minutes without paging anyone for a blip.

Set a mute period

When a site stays down, repeated notifications every minute turn into noise. A mute period controls how long CloudMonitor waits before it resends an unresolved alert. Set it long enough to avoid spam, but short enough that a forgotten incident gets another reminder.

Match severity to the response

Not every alert deserves a phone call. Use tiers:

Severity	Example condition	Notification channel	Expected response
Critical	Landing page failing from multiple locations	SMS or phone, plus chat webhook	Respond within minutes
Warning	Response time above threshold for 5 minutes	Email and chat webhook	Check within the hour
Info	Certificate expires in 30 days	Email	Handle during working hours

CloudMonitor supports several notification channels, including email, SMS, and webhook targets such as a DingTalk chatbot. Put the critical alerts where someone will see them out of hours if you run campaigns on weekends or overnight.

Use the effective period

Alert rules have an effective period, which controls when notifications are sent. If a campaign runs only in certain hours, you can limit loud alerts to those hours and route off-hours failures to a lower-priority channel. If you run ads around the clock, leave the rule active all day.

Make the page harder to take down

Monitoring tells you about problems. Resilience reduces how many problems happen.

Serve static pages from a CDN. A landing page that is mostly static HTML, CSS, and images does not need a live application server for every visit. Hosting it on Object Storage Service (OSS) behind Alibaba Cloud CDN removes the application server from the failure path. The walkthrough on hosting and scaling marketing landing pages on Alibaba Cloud OSS and CDN covers the setup.

Spread across zones. Run at least two ECS instances in different zones behind SLB. If one zone has a problem, the load balancer keeps sending traffic to the healthy one.

Handle slowness as an availability problem. A page that responds in many seconds loses visitors almost as surely as one that returns an error. The guide on improving Core Web Vitals with Alibaba Cloud CDN and ECS explains how caching and server tuning reduce response times, which also lowers the number of slow-response alerts you receive.

Track expiry dates. Expired TLS certificates and domain registrations cause outright outages, and they are entirely predictable. Set calendar reminders or alerts at 30 and 7 days before expiry, and enable auto-renewal wherever your certificate and domain setup supports it.

Test deployments before they reach ad traffic. Many landing page outages come from a bad release, not hardware failure. Deploy to a staging address, run the same content check against it, and only then switch ad traffic. If your team ships updates during active campaigns, keep a quick way to roll back to the previous version.

Balance resilience against cost. More redundancy costs more. For a small campaign, a static page on OSS and CDN with external monitoring may be enough. For a large launch, multi-zone ECS and Auto Scaling are justified. The tips in Optimizing Cloud Costs on Alibaba Cloud: Practical Tips for Small Teams help you size the setup to the budget.

What to do when an alert fires

A short runbook saves minutes when stress is high. Keep it somewhere the whole team can find it.

Confirm the failure. Open the page yourself and check the site monitoring results from multiple detection points. Decide whether it is a full outage, a regional issue, or a false alarm.
Reduce the damage. If the page will stay down for more than a few minutes, pause the affected ad campaigns on the ad platform. Paused ads stop spending on a page that cannot convert.
Find the cause. Check the SLB backend status, the ECS metrics, and the recent error logs in Log Service. Look at recent deployments first, since they cause a large share of incidents.
Fix or roll back. Roll back a bad release, restart a failed service, or scale out if the cause is load.
Verify recovery. Wait until the external checks pass from several locations before you re-enable ads.
Record what happened. Write down the timeline, the cause, and one change that prevents a repeat. Add any missing check to the monitoring setup.

The decision to pause ads in step 2 is the one that saves the most money, and it is the one teams most often delay. Agree on the threshold in advance, for example "pause if the page has failed checks for ten minutes".

Pre-launch checklist

Use this list before every campaign goes live.

[ ] Landing page URL, form endpoint, and confirmation page each have an HTTP(S) site monitoring task
[ ] Each task checks status code, response time, and a content string
[ ] Detection interval is set to one minute for the campaign period
[ ] Alert rules use consecutive failure counts to avoid false alarms
[ ] Critical alerts reach someone who is awake during campaign hours
[ ] SLB health checks point to a real health endpoint
[ ] At least two backend instances run in different zones, or the page is static behind a CDN
[ ] TLS certificate and domain expiry dates are checked and have reminders
[ ] Logs are flowing to Log Service and a basic error dashboard exists
[ ] The team has agreed on when to pause ads during an outage
[ ] A rollback path exists for the latest release

Common mistakes

Monitoring only the home page. Ads send traffic to specific URLs. Monitor those exact URLs, with the same path and parameters.

Relying on status code alone. A 200 response with a blank page passes the check. Add a content match.

Checking from inside your own network. A check running on the same server or VPC can miss DNS, certificate, and routing problems that visitors see. Use external detection points.

Setting alerts with no owner. An alert sent to a shared mailbox that nobody reads is the same as no alert. Name a person or an on-call rotation.

Skipping tests of the alert path. Trigger a test alert once to confirm the SMS, email, and chat messages arrive. Many teams discover a typo in a phone number only during a real outage.

Forgetting to re-check after changes. A new landing page template or a changed URL structure can break the content match string. Update the monitoring task whenever the page changes.

Wrap-up

Paid traffic only works when the page behind the ad works. Downtime wastes spend, can disable ads, and corrupts the conversion data that bidding depends on. Catching problems quickly, and preventing the preventable ones, protects the budget more directly than most optimization work.

A practical setup on Alibaba Cloud needs only a few parts: external HTTP(S) checks in CloudMonitor with status, speed, and content rules; SLB health checks for the backend servers; host metrics and Log Service for diagnosis; and alert rules that reach a person who can act. Add resilience with a CDN-hosted static page or multi-zone servers, and write down a short runbook so the first ten minutes of an incident follow a plan.

Start small. Create one site monitoring task for your most important landing page today, add a content check, and send the alert to someone who will see it. Then expand to the rest of the chain, one step at a time.

If you manage ad delivery systems as well as landing pages, the guide on optimizing digital advertising workflows with Alibaba Cloud Container Services covers the container-based side of that work.

Disclaimer: The views expressed herein are for reference only and don't necessarily represent the official views of Alibaba Cloud.

Community