How to Set Up Monitoring for a Web Application in 6 Steps

You can find out that your application is down in two ways. A dashboard tells you within minutes. Or a customer emails on Monday morning, asking why they could not check out on Saturday night. What separates those two is a monitor, and for a single web app it takes about fifteen minutes to set one up.

Starting from zero monitors, this guide follows the whole sequence on a monitoring dashboard: creating the first one, deciding who gets alerted and when, running the first check by hand, validating what an API actually returns instead of only whether it answers, reading the stored result of a failed check, and setting the account defaults once so you do not have to repeat yourself on every monitor after that.

Tools use different field names. The sequence stays the same, and so do the decisions, which are the part worth getting right. The audience here is whoever owns the app, not a dedicated operations team, so nothing below assumes an on-call rotation is already in place.

Step 1: create the monitor with a name, a type, a URL and an interval

Four pieces of information are required for a monitor. The rest of the creation form is optional, and most of those fields only show up after you choose a type.

1. Name it for the alert, not for the list. This name will reach you in a notification, out of context and probably on a phone. "Checkout API, production" is useful. "Monitor 4" is not.
2. Select the monitor type. Website for an HTML page, API for a JSON endpoint, image for an asset you serve from a CDN. The type decides which validation options the form offers further down, so it is worth getting right the first time.
3. Enter the URL that matches the type. Use the full address with the http:// or https:// scheme. Point a website monitor at a JSON endpoint and it will run happily while telling you nothing useful.
4. Set the check interval in minutes. On the form shown here the default is ten. The help text under the field describes the whole behaviour: after the interval, the monitor is checked automatically.
5. Leave Autocheck enabled. With it disabled, the monitor only ever runs when you press Run yourself. That is handy while you are still configuring it, and useless once it is live.
6. Click Proceed. Before you can save, the URL gets validated, so a typo shows up here instead of turning into a permanently red monitor tomorrow.

Before accepting the default interval, consider this: it is also your worst-case detection delay. With a ten-minute interval, an outage starting thirty seconds after a successful check goes on for nearly ten minutes before anything notices. Tighten the interval on the paths that take money. Leave the marketing pages alone.

Step 2: decide who gets the alert, and when it fires

In Alert Configuration, type an email address and press Enter; it turns into a chip below the field. Do the same for each recipient. An empty field does not mean nobody is told, because the default address from the account settings is used instead (step 6 covers it).

The line under that field is the most important sentence on the page, and the one most people skim past: emails are notified on status changes, up to down or down to up. Not on every check. Not on every failure. Only on the transition.

Two consequences follow from that, and both of them matter more than the setup itself.

• A long outage sends one email, not hundreds. One message arrives when the service goes down, and another when it comes back. Your inbox gets through a six-hour incident.
• A flapping service is loud, and should be. When something drops and recovers every few minutes, each cycle generates two transitions. Relentless mail means the signal is real, since intermittent failures are usually worse than clean ones and harder to reproduce.

The same transition rule applies to chat notifications. Routing alerts into a team channel changes the destination, not the volume.

Just above Alert Configuration sits the Authentication section, and it is not optional for anything behind a login. A monitor hitting a protected URL with no credentials gets a 401 and reports down forever, which at least is obvious. The nastier outcome is a login wall that returns a cheerful 200, in which case the monitor reports up while the application behind it is broken.

Step 3: run the first check before you trust the schedule

Save Monitor adds a row to the dashboard. That row is honest about what it knows: status Pending, uptime 0%, latency N/A, last check Never. No check has run yet. The monitor exists, and that is all.

Click Run. A confirmation toast pops up and a live status card slides in with the monitor name, its latency and its type, while the row updates in place: status Up, uptime, latency in milliseconds, last check a few seconds ago. This round trip is the real test. It is also why you do it by hand instead of waiting for the interval to come round.

The manual run tells you three things the configuration form cannot:

1. The URL, the credentials and the validation all work together. Any one of them can be right alone and wrong in combination.
2. What normal latency looks like. Your baseline is that first measurement. Without it, a slow response next month is only a number.
3. That the monitor leaves Pending. Once you have set up several at a time, filter the dashboard by Pending. Anything still sitting there never ran, and a monitor that never ran monitors nothing.

Once you have more than a handful, group them into collections. Monitors you have not assigned appear under Uncollected Monitors, which is a reasonable staging area and a poor permanent home. Splitting by environment is the usual first cut, and it is worth pointing monitors at your staging environment too, so a broken release is caught before it reaches production traffic.

Step 4: validate what the API returns, not just that it answered

You start an API monitor the same way, with a name, a type and the http or https URL of the endpoint. Here, though, Proceed behaves differently. Rather than only validating the address, it calls the endpoint, retrieves a live response and parses it, so you can say what a healthy answer looks like.

You get two columns. Available, on the left, lists every key the tool found in the response; Selected, on the right, holds the ones that will be checked. Move the keys that matter across. Every check validates those selected keys, and they decide its status. A free-text field also lets you add a word or sentence the response must contain, which is the fallback when the shape of the payload is not helpful.

That is the entire case for an API monitor over a plain uptime check. An endpoint returning HTTP 200 with a body that says the service is degraded will pass an uptime check and fail a content check. The status code tells you the web server is alive. Whether the product works is what the payload tells you.

Pick stable keys. A good signal is a field present on a healthy response and absent or different on a broken one. By contrast, a field that only shows up when there is data in the system will page someone at 3am the first quiet night. If the endpoint needs a token or a key, fill in the Authentication section before saving, then save and run it once, exactly as in step 3. The natural next move is wiring these checks into your deployment pipeline as a post-release step, since the response shape is most likely to change on the day you ship.

Step 5: read the history when something looks wrong

Alerts say that something changed. History says what happened, and it is the half of monitoring that people set up and then never open until the first incident.

On a monitor row, the History button opens its check statistics together with the recent checks. Each row in there has a View Details link, which is where the stored evidence is kept: status, HTTP status code, latency and the exact time the check ran.

What sits below the header depends on the monitor type.

• Website monitors keep the response in three forms. Summary gives you the page title and the extracted page text, Page preview renders what the checker saw, and Raw HTML is the unprocessed document. The panel states explicitly that very large responses are truncated.
• API monitors keep the response data, plus a Show raw JSON toggle for when you need the unformatted payload.
• Metadata on both includes the check ID and the monitor ID. Paste those identifiers into a ticket, rather than a screenshot and an approximate time.

A log across every monitor exists too. It shows the total checks in the last 24 hours, how many succeeded, how many failed and the resulting success rate, plus a table that lists each check with its HTTP status and latency and updates in real time.

The payoff is concrete. If somebody says the site was slow yesterday afternoon, the latency column settles it in about ten seconds. For a failed check, the stored response tells you whether it was a 500, a timeout, or a page that rendered an error message and returned 200 anyway, the failure mode that uptime percentages hide.

Step 6: set the account defaults once

Four settings deserve five minutes now, instead of being rediscovered during an incident.

• Default alert email. This address receives alerts from every monitor unless that monitor names different recipients. Point it at a shared inbox or an alias rather than a personal address: people change roles and leave companies, aliases do not.
• Recovery alerts. One checkbox controls whether you are told when a monitor comes back online. With it on, you get both edges of every incident, including the one telling you it is over. Turn it off and only failures reach you, which the setting itself notes is the quieter option.
• Latency mode. Switch the display between milliseconds and seconds. Milliseconds for APIs, where the differences that matter are small; seconds for pages, where they are not.
• Language. Set once per account.

None of this affects what is monitored. Instead, it changes how much of your attention each alert costs, and over a year that is what decides whether anyone still reads them.

Mistakes that make monitoring useless

• Monitoring only the homepage. That is usually the most cached, most static page you own. It stays green while login, checkout and the API behind them are all broken.
• Leaving monitors in Pending. On the dashboard they look configured, yet they check nothing. After any batch of setup work, filter by Pending.
• Skipping the Authentication section on a protected URL. In the best case, the monitor is permanently red and you stop reading it. Worst case, a login page returns 200 and the monitor is permanently, wrongly green.
• Validating an unstable key. When the field only appears if there is data, the monitor is measuring your traffic, not your uptime.
• Sending every alert to one personal inbox. That works right up to the moment the person is on a plane.
• Editing a monitor and not running it. Nothing gets re-checked when you change a URL, a credential or a validation key. The last result on screen still describes the old configuration.
• Treating a tight interval as free. If you check everything every minute, each deploy blip becomes a transition, and transitions are exactly what send mail.

Fifteen minutes now, or a customer email on Monday

It is a short sequence. Name and type the monitor, point it at the right URL with a sensible interval, decide who hears about it (and remember that only transitions send mail), run the first check by hand, validate the response body rather than the status code alone, and set the account defaults once. Step 5 is the work that pays off later: the first time something breaks, you will want the stored response, not a notification that something broke.

Begin with the paths that take money or lose customers. Get those green and trusted, then widen. If nobody on the team owns this once it is running, our vetted network can staff it: start with hiring DevOps engineers and specify which services need watching.