How-to
Uptime and journey monitoring
Check your storefront from the outside on a schedule, or have your own app report each transaction, and get paged when checkout goes down.
Jump to section
What it does
Every other detector in Edge reads your traffic logs. Uptime monitoring is the one that works the other way round: it checks your storefront from the outside, on a schedule you set, and opens an alert when a page or a checkout journey stops responding correctly. This is what tells you the site is down before your shoppers do, and it keeps working even if the log feed itself goes quiet.
Open the Uptime page from the sidebar. The list shows each monitor with its current status (up, down, degraded), last latency, and when it was last checked.
Three kinds of monitor
Click Add monitor and pick a type.
Single URL
A periodic check of one address. Set:
- URL, for example your homepage or
/checkout - Page must contain (optional): a phrase that has to appear in the response, so a page that returns a 200 but serves an error still counts as down. "Add to Basket" is a good one for a product page.
- Check every: 1, 5, or 15 minutes, or hourly. Five minutes suits almost everything. Reserve one minute for your few most critical endpoints, since it adds load to your origin.
- Severity when down: Critical or Warning.
Journey
An ordered sequence of up to ten steps that carries the session between them, so you can watch a real path such as home, category, product, add to basket, start checkout. If a step fails, the alert tells you which one. Same schedule and severity controls as a single URL.
Reported (beacon)
For a step a synthetic check cannot safely run, such as a form behind a CAPTCHA or a real payment you must not fake, your own application reports the outcome instead. See "Reporting from your own app" below.
From failure to alert
A monitor does not page you on a single blip. It opens a url_down alert after three consecutive failures by default, and clears it after two consecutive passes. A page that is up but slow opens a separate warning instead of a full outage alert, if you set a degraded-latency threshold on the Edit form. You can change the fail and recover thresholds per monitor. Alerts reach you through your normal channels (email, Teams, Slack, webhooks), and a url_down alert correlates into an incident with any related detector, so "the origin is slow" and "checkout is down" arrive as one story rather than two.
The detail page
Open any monitor to see uptime percentage, average and 95th-percentile latency, and a bar strip of recent checks (green passed, red failed) over 24 hours, 7 days, or 30 days, plus a table of the most recent checks with the failure cause. Latency is measured from Blankitt's network, so read it as a direction of travel rather than the exact speed a shopper sees. Use Check now to run an immediate check, and Pause while you do planned maintenance.
Reporting from your own app
When you create a Reported (beacon) monitor, Edge shows you a one-time secret and an endpoint. The secret is shown once and cannot be retrieved again, so copy it then. Configure your application to POST each transaction outcome:
- Endpoint: the beacon URL shown on screen
- Body:
{ "monitor_id": "...", "event": "...", "outcome": "success" | "failure", "reason": "...", "latency_ms": 123 } - Header:
X-Edge-Signature, set to the hex HMAC-SHA256 of the raw JSON body using your beacon secret
A failure outcome opens the alert; the next success clears it. The monitor
must be active for beacons to be accepted (a paused one rejects them). To
rotate the secret, recreate the monitor.
Tips
- The number of monitors you can run depends on your plan. If you hit the limit, Edge tells you which plan lifts it.
- Put the pages that cost you money first: checkout, add to basket, login, search. A homepage check tells you far less than a checkout journey.
- A journey is worth more than several separate URL checks of the same path, because it proves the steps still work together, not just individually.