Start with the question each URL answers
Choose a monitor by deciding what you need to know when it fails. A homepage monitor answers whether the public address can return a successful HTTP response. An API health endpoint can answer whether a particular application is ready to accept work, provided the endpoint actually checks that condition.
Write that question beside each proposed URL before adding it. “Is the public marketing site reachable?” and “Can the API reach the database it needs?” describe different observations. Adding several URLs that all return the same static page can produce several alerts without giving you different evidence.
UpBastion has 10 monitors per account. A useful first set often includes the main public website and one public endpoint for each independently deployed application you need to observe. This is a planning example, not a prescribed architecture or a claim about your infrastructure. Keep room for another endpoint when you can explain what it reveals.
Monitor the public address people actually use
Start with the canonical HTTPS URL of your website. Test the exact scheme, hostname and path. A monitor for an old address redirecting to the canonical address also tests that redirect, which is useful when the old address remains in links. It introduces another dependency into the result.
UpBastion follows up to five redirects and succeeds only when the final response is HTTP 2xx. A homepage redirecting to a working login page can therefore appear up even when the intended authenticated application is unavailable. The worker has no login session and does not inspect page content. Read check behavior before treating a green result as evidence of a complete customer journey.
For a CDN-backed site, the public URL observes the CDN's response to the monitoring server. A cached page can keep responding while an origin problem affects other requests. If you also need an application-readiness signal, create and monitor a separate public endpoint whose caching behavior matches that purpose. Decide this in the application and proxy configuration; UpBastion cannot infer it from the address.
Design a health endpoint with a clear contract
A health endpoint should return a successful HTTP status only when the condition it represents is satisfied. For example, a readiness endpoint can return 200 when the application can perform a small dependency check and 503 when it cannot. MDN's explanation of 503 describes the status; the actual dependency checks are your application's responsibility.
UpBastion evaluates status codes, so an endpoint returning 200 with {"healthy":false} is still successful to the monitor. Return a non-2xx status for a condition you intend to count as unavailable. Do not put connection strings, internal hostnames, customer records or diagnostic dumps in a publicly reachable response.
Use lightweight, bounded checks. A health request should not create orders, send emails, run migrations or make a costly write on every poll. The HTTP semantics specification describes GET as a safe method; ensure your own endpoint does not attach unintended side effects to it.
A public endpoint must be reachable without custom headers, credentials or browser cookies. UpBastion does not support monitoring a private network, a bearer-token-protected request or a POST-based workflow. Avoid moving a secret into a URL query as a workaround: URLs are stored and included in alerts. See supported addresses.
Understand the check interval
Regular checks are due five minutes after the previous result is saved. A first failure schedules another check after 30 seconds, and that confirmation must fail before an incident opens. Execution can be later than its due time when the worker is busy or unavailable.
An outage that starts and ends between observations can be missed. An incident start records the first observed failure in the confirmed sequence. It is not the exact moment the application first stopped working. Use application logs, request metrics and user reports when those distinctions matter.
This makes the monitor useful for detecting observed HTTP availability problems. It does not provide a one-minute interval, several probe regions or a browser transaction test. If your requirements include a successful checkout or a very short detection target, add a method that directly measures that requirement and keep the UpBastion monitor for its stated role.
Name monitors so alerts are actionable
Use names that identify the environment and component, such as “Production API readiness” or “Marketing homepage”. Avoid a generic “Website” when you have several endpoints. An email includes the monitor name and full URL, so the name should help you locate the relevant deployment.
Create the monitor through the dashboard, then inspect its first recorded result. Compare that result with a manual request. If the result is unexpected, check redirects, authentication, certificate validation and access rules before changing the endpoint's status logic.
When replacing an endpoint, decide whether its old history should remain with the new address. Editing a URL retains check history but resets the state and certificate metadata. A new monitor keeps the histories separate. The steps are in creating and managing monitors.
Test the path from failure to recovery
Use a test endpoint you control. Let it return a known successful status, then change it to a known failure without disrupting a production service. Wait for the first failed observation and confirmation, and inspect the resulting incident. Restore the successful response and check the recovery observation.
Check the account's verified primary mailbox during the test. A queued message can be delayed, and a receiving system can filter it. There is no built-in test-email button. Email alerts explains recipients, retries and duplicate delivery.
Record the URL's purpose, expected status behavior and the person who can investigate it in your own operational notes. Revisit that choice after a deployment or infrastructure change. For the next failure, use the incident investigation guide and the HTTP error guide.