To prevent a momentary network blip from paging your on-call engineer:
Acumen Logs routes failure and recovery notifications to the channels your team already uses:
You can assign different alert channels to different monitors (for example, routing checkout failures to #incidents-critical in Slack while sending SSL reminders to email) and test any channel with one click.
You can track web performance from both outside probes and real user browsers:
Most people finish the first monitor in about a minute.
Tools that track whether a URL answers include:
Uptime monitoring is useful when you need a record of whether an endpoint answered, not a recording of a user clicking through the product.
Public status pages are a separate product. They can show availability to customers. They are not built into the uptime check itself.
How a check runs
Create an uptime test, name it, and enter the target URL. The request can be GET or POST. Intervals are every 1, 5, 10, or 30 minutes. The setup guide uses 5 minutes as the default example.
What counts as a failure
You choose the status codes that count as healthy. The default is 200–299. Add 301 or 302 when a redirect is expected. You can also fail the run when latency crosses a millisecond threshold, when the body is missing a required string, or when it contains a string you do not want. Each run stores the status code, response time, headers, host IP, and DNS resolve time. Certificate checks can sit on the same test.
When an alert is sent
Uptime alerts go to email, Slack, Microsoft Teams, desktop, or webhooks. Each channel has its own consecutive fail count. The alert docs suggest starting email at 2–3 failures and Slack or Teams at 2. Use Test Alert to confirm delivery. A maintenance window can mute alerts during planned work.
Trusted by Top-tier product companies
.avif)
