How to Monitor a Web App for Free

Use several small checks instead of one “is the homepage up?” check. Start with an external HTTP monitor, then add keyword validation, API checks, and browser checks for login or checkout. Configure alerts, test them, and keep the monitor outside your app’s hosting environment when possible.

1. Choose what to monitor

A web app can return HTTP 200 while showing an error page, an empty application shell, or a broken data request. Create separate monitors for:

Public availability: DNS, TLS, routing, and basic HTTP reachability.
Expected content: a keyword or phrase that must appear in the response.
Important APIs: health, authentication, payments, webhooks, and other dependencies.
Critical user journeys: login, checkout, signup, or search flows that require several successful actions.
Certificate and domain expiry: where your monitoring provider supports these checks.

Place checks outside the infrastructure that hosts the app. A monitor running on the same server, network, or cloud region can fail at the same time as the app and hide the outage.

2. Fastest hosted setup: UptimeRobot

UptimeRobot’s documented free plan includes 50 monitors, five-minute checks, one status page, and HTTP/website, keyword, ping, port, and heartbeat monitoring. The plan is documented as requiring no credit card and allowing commercial use. Limits and integrations can change, so verify the current provider documentation before relying on a quota.

Create an account and add an HTTP(s) monitor for your public URL.
Use the final HTTPS URL, including any required path.
Set the expected status to a successful response.
Add a keyword monitor for text that proves the application rendered correctly.
Add separate monitors for APIs and critical endpoints.
Configure at least one alert channel that someone actively watches.
Trigger a test alert and confirm that recovery notifications also arrive.
Publish a status page if users or clients need incident visibility.

A five-minute interval means detection and recovery reporting can wait until the next scheduled check. It is useful for many small sites, but it is not one-minute detection.

3. Add keyword and API checks

Use a keyword check when a successful HTTP response can still be an error page or empty shell. Choose stable text such as a page heading, account name, or build marker. Avoid timestamps, rotating recommendations, localized text, and content that changes on every request.

Monitor APIs independently because a working homepage does not prove that authentication, payments, webhooks, or database-dependent endpoints work. Prefer a small read-only health endpoint that returns a predictable response. If authentication is required, use a restricted monitoring account or a token with only the permissions needed for the check.

Minimal shell check with curl

#!/usr/bin/env bash
set -euo pipefail

URL="https://example.com/health"
EXPECTED="ok"

body="$(curl --fail --silent --show-error --location --max-time 20 "$URL")"
if [[ "$body" != *"$EXPECTED"* ]]; then
  echo "Expected marker not found" >&2
  exit 1
fi

echo "healthy"

Run this from an external scheduler or CI system. Store credentials in secrets, never in the script.

An HTTP check cannot prove that a multi-step journey works. Use a browser transaction check when the flow must:

Load a page and its JavaScript bundle.
Accept or dismiss a consent dialog.
Enter credentials or customer data.
Submit a form and follow a redirect.
Display a confirmation or account page.

Better Stack’s monitor API documents HTTP status, expected-status-code, keyword, ping, TCP, UDP, SMTP, POP, IMAP, DNS, and Playwright monitor types. A Playwright scenario can open a login page, submit credentials from environment variables, and verify the resulting page. Check the current pricing page for the active free allowance for each monitor type before treating it as a zero-cost plan.

Example Playwright transaction

import { chromium } from "playwright";

const browser = await chromium.launch({ headless: true });
const page = await browser.newPage();
try {
  await page.goto("https://example.com/login", { waitUntil: "networkidle" });
  await page.getByLabel("Email").fill(process.env.MONITOR_EMAIL);
  await page.getByLabel("Password").fill(process.env.MONITOR_PASSWORD);
  await page.getByRole("button", { name: "Sign in" }).click();
  await page.getByText("Dashboard").waitFor({ state: "visible", timeout: 15000 });
  console.log("login flow healthy");
} finally {
  await browser.close();
}

Use a dedicated test account, avoid real purchases, and make the transaction safe to repeat. Mask credentials in logs and clean up created test data.

5. Self-host with Uptime Kuma

Uptime Kuma is open-source, self-hosted monitoring software with Docker deployment instructions in its repository. It removes license fees, but you operate the host, updates, backups, network access, notifications, and security. Do not place it on the same infrastructure as the app unless you also have an independent check.

A typical deployment process is:

Provision an always-on host with persistent storage.
Deploy Uptime Kuma using the project’s documented Docker instructions.
Restrict administrative access and configure HTTPS.
Add HTTP, keyword, API, and heartbeat monitors.
Configure notifications and test both failure and recovery.
Back up the monitoring data and update the container regularly.

6. Configure alerts and a status page

Alert on consecutive failures when the provider supports it, reducing noise from one transient request.
Send alerts to a channel with an on-call owner.
Include the monitor name, URL, first-failure time, last-success time, and response details.
Send a recovery notification so incidents close visibly.
Use a status page when customers need a single incident view.
Review alert delivery after changing credentials, domains, or notification integrations.

7. Troubleshooting

Symptom	Likely cause	Fix
Monitor reports down while the site works in a browser	Firewall, allowlist, DNS split-horizon, or region-specific routing	Check requests from the monitor’s documented locations and allow only the required ranges.
HTTP check is green but users see an error	HTTP 200 with an error page or empty shell	Add a stable keyword check and monitor the API that supplies page data.
Frequent false alerts	Transient network failure, slow cold start, or an overly short timeout	Use a realistic timeout, require consecutive failures, and inspect provider history before changing application code.
Keyword check fails after a redesign	Selector or text changed	Choose a stable heading or build marker and update the monitor with the deployment.
Browser flow cannot log in	Expired credentials, MFA, CAPTCHA, changed selectors, or bot protection	Use a dedicated account, stable selectors, a test-safe path, and a supported authentication strategy. Do not disable security controls on production accounts.
Self-hosted monitor stops with the app	Monitor shares the same host, network, or power source	Move it to another provider or location and retain an independent hosted check.
No recovery alert arrives	Recovery notifications disabled or integration token expired	Run a controlled failure, inspect notification settings, and rotate the integration credential.

8. Performance, reliability, and cost

Detection delay: interval-based checks can detect an outage only on a scheduled request; five-minute checks are not continuous observation.
Request load: keep health endpoints small and read-only. Do not run expensive reports or real payment operations on every check.
Geographic coverage: checks from multiple regions can reveal DNS, CDN, and routing problems that one location misses.
False positives: combine status, content, and consecutive-failure rules instead of making one slow dependency determine the whole alert.
Retention: compare history length, incident exports, and status-page behavior before selecting a provider.
Free-plan limits: quotas, intervals, alert channels, and commercial-use terms can change. Recheck the provider’s current documentation.
Self-hosting cost: Uptime Kuma has no license fee, but the host, storage, maintenance, backups, and operator time still have a cost.

9. Or skip the browser setup

When the goal is a clean visual check of a page, ScreenshotNeo can capture it through one request. See the ScreenshotNeo API documentation for the available options.

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

import requests
r = requests.get("https://api.screenshotneo.com/v1/shot", params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"}, timeout=90)
open("shot.webp", "wb").write(r.content)

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);

ScreenshotNeo accepts consent banners before capture and removes more than 60 known consent platforms, newsletter popups, and chat widgets. Bot checks, blank pages, failed loads, timeouts, and cache hits are not billed, and each response identifies the page verdict and billing result in X-Page-Verdict and X-Billed headers. Its MCP server provides take_screenshot, get_page_info, and capture_pdf for Claude, Cursor, and other MCP clients. The Free plan includes 1,000 screenshots per month with no card; paid plans start at $5 for 3,000 shots. Create a free ScreenshotNeo account.

10. Practical setup checklist

External HTTP monitor for the public app.
Keyword check for expected rendered content.
Separate monitors for important APIs and webhooks.
Browser transaction for login, checkout, or another critical path.
SSL and domain-expiration checks where available.
Alerts tested for both failure and recovery.
Monitor hosted outside the app’s infrastructure.
Status page enabled when users need incident visibility.

FAQ

Can I monitor a private app for free?

Yes, if the monitoring service can reach it through a secured network path. Otherwise expose a narrowly scoped health endpoint or run a self-hosted monitor inside the private network, while retaining an independent external check for the public edge.

Is a ping monitor enough?

No. Ping proves network reachability, not that HTTPS, routing, application content, or dependencies work. Pair it with HTTP and keyword checks.

How many checks should a small app have?

Start with the homepage, one stable keyword, the most important API, and one critical user journey. Add monitors when a dependency or customer path has a distinct failure mode.

Should I choose hosted monitoring or Uptime Kuma?

Choose hosted monitoring when you want the quickest setup and an independent location. Choose Uptime Kuma when you already operate an always-on host and accept responsibility for maintenance, backups, and notifications.