Monitor an API and get alerts

Check a request or a suite every few minutes, see its health, and hear when it fails and recovers.

In short

A monitor checks one saved request, a whole suite, or every request of a project, a team's projects or the organization's, and tells you when it starts failing and when it recovers. Each monitor shows its state, uptime and incidents. Alerts go by email or to your Slack, Teams or own service.

Before you start

Create a monitor

  1. From a request: once it works, press "Save as monitor". It keeps the request in a project and opens the monitor's form. Later, a saved request's menu also offers "Save as monitor": a small form in the sheet, with how often and where, and Undo on the message - save your changes first, because a monitor checks the saved request.
  2. From "Watch" › "Monitors": press "New monitor" and choose "One request" or "A suite".
  3. Give it a "Name" (one is suggested), pick the environment (leave it to use the request's own) and "How often".
  4. Open "Alerts" to change how it alerts - "Email me" and up to five webhook endpoints. It says what it is set to while folded.
  5. Press "Create monitor".

Result: the monitor waits for its first check, then shows Up or Down with a strip of its latest checks.

Not on your plan? "Save as monitor" appears only where your plan includes monitoring. Free allows basic monitors: one GET or HEAD request, checked every 15 minutes or less often. Shorter intervals, suites, other methods and sign-in requests need a higher plan, and the dialog says which rule a monitor would break before you save it.

What it costs: checks a day

"How often" is "Every few minutes" - an interval - or "At a set time": every hour, or daily, weekly or monthly at a time of day on a time zone's clock, your own zone at first, so 09:00 stays 09:00 when the clocks change. A monitor at a set time first checks at its next planned time, and the plan weighs it as one check an hour, a day, a week or a month. As you choose, the dialog shows the cost. It shows "Every 5 min = 288 checks a day" (or "Daily at 09:00 = 30 checks a month") and how many requests each check sends. It also shows how many sign-ins a day, about how many requests a month, and whether that fits your plan's monitor checks. A suite counts every request of every step, and a login request counts once each time the token is renewed. Monitor checks have an allowance of their own, so they never use up the requests you send by hand.

State, health and incidents

Open a monitor, or "Health and incidents" in its row menu, to see uptime over a day, a week and 30 days, and each incident - for example "down 14:05, recovered 14:20". Beside it are what the monitor checks, how often, the next check, whose rights it runs with and where it alerts; "Run now", "Change", "Run history" and "Daily history" sit at the top, and "Related" and "Activity" are tabs of their own. A check {{brand}} could not send, such as one to a private address, changes nothing.

Run it now and read its runs

  1. Open "Watch" › "Monitors" and press "Run now" on the monitor's row, or at the top of its sheet. It runs at once, as you and on your API requests, even while the monitor is off. You need Run on its project.
  2. Read the message: how many passed and failed. On a failure, "Review failures" opens what failed; otherwise "Run history" opens the monitor's runs.
  3. To see every run, choose "Run history" in the row's menu or at the top of the monitor's sheet. Each run says how it ended, how many passed and failed, how many projects and requests it ran, how long it took and who pressed "Run now".
  4. Press "Review failures" on a failed run to open what failed, and "Show older runs" to go further back.

Alerts

Test environments stay quiet

Local, Development, QA, Staging and custom environments are for trying things out, so a failure there does not alert you unless you turn on "Also alert outside Preprod and Production". Failures in Preprod and Production always alert.

If something goes wrong

Related