Skip to content
Leaflow
Get started

Observability

Monitoring

Host metrics pushed by an agent, multi-step web checks, alerts with readings, charts and a timeline, SLOs, and a public status page in the same project.BillingFree for now. A top-up of at least US$1 is still required before using Leaflow.

Open in the ConsoleView pricing
MonitoringAll healthy

SLA · this period

99.982%

6 minutes of error budget left

Web checks

  • blog.example.com200 · 182 ms
  • api.example.com/health200 · 96 ms

Public status pagestatus.example.com

45 days agoToday

At a glance

MonitoringAll healthy

SLA · this period

99.982%

6 minutes of error budget left

Web checks

  • blog.example.com200 · 182 ms
  • api.example.com/health200 · 96 ms

Public status pagestatus.example.com

45 days agoToday

A check requests the page on an interval and verifies status codes and response content at each step, alerting only after consecutive failures reach the retry count.

The agent connects out, so no inbound ports are needed.

Register the machine in the Console, choose how it is collected, and bind templates to get the agent configuration. In active mode the machine connects to the monitoring service, and the first reading usually appears within a minute. In passive mode the platform connects to the machine, so its agent port must be reachable. The key returned at enrollment is shown once; if it is lost after collection starts, rotate it.

Active

  • The machine connects to the monitoring service
  • No inbound ports to open
  • First reading usually within a minute of the agent starting

Passive

  • The platform connects to the machine
  • The agent port must be reachable, 10050 by default
  • Changing the collection mode rebinds templates to the matching variant

Base templates watch the machine; service templates watch what runs on it.

Templates decide which metrics are collected and where the alert thresholds sit. Every machine binds one operating system template; add the service and hardware templates that match what is installed. A template bound to a service that is not installed keeps failing collection.

Base template

  • CPU utilization, load average, context switches and interrupts
  • Memory, swap, and available memory
  • Filesystem space, inodes, and disk I/O
  • Network throughput, drops, and interface state
  • Process count, logged-in users, and uptime
  • Linux or Windows

Service and hardware templates

  • Systemd units, Docker containers, and images
  • Nginx connections and requests, PHP-FPM pools and queues
  • Certificate expiry and S.M.A.R.T. disk health
  • NVIDIA GPU utilization, memory, temperature, and power
  • ICMP Ping and Proxmox VE, without an agent on the machine
  • Thresholds come from the template parameters

Every step must pass, with the expected status code and content.

A check requests its addresses in order on a set interval. Steps share one session, so a check can sign in before visiting a page. Each step sets the expected status codes, a string that must appear in the response body, and whether to follow redirects. A run is unhealthy only after consecutive failures reach the retry count. The default interval is 60 seconds; the interval, timeout, retry count, and response time threshold can all be changed. A check can belong to a machine, or watch a URL on its own.

  • Every 60 seconds by default; interval, timeout, and retry count can be changed
  • Status code, response content, and response time can all be checked
  • A check can belong to a machine or watch a URL on its own
MonitoringAll healthy

SLA · this period

99.982%

6 minutes of error budget left

Web checks

  • blog.example.com200 · 182 ms
  • api.example.com/health200 · 96 ms

Public status pagestatus.example.com

45 days agoToday

The reading, the charts and the handling record are all on one alert.

Alerts are graded by severity and sent to every member of the project. The detail page shows the trigger condition, the reading at the moment it fired, the metric charts around the event, and a timeline of firing, recovery, acknowledgment, assignment, notes, and closure. You can claim an alert, add notes, follow it, and close it with a reason. Alerts also go to EventBus as platform events, so a Shipping task can subscribe and act on them.

In the alert

  • Severity: not classified, information, warning, average, high, or disaster
  • Trigger condition and the reading when it fired
  • Charts for the monitored items around the event
  • Timeline: fired, recovered, acknowledged, assigned, followed, noted, closed
  • The machine or web check it belongs to

What you can do

  • Claim it or assign it to a project member
  • Add a note and follow later changes
  • Close it with a reason: fixed, recovered, accepted risk, duplicate, false positive, no action needed, or other
  • Close an alert that has recovered but is not handled yet
  • Reopen it after closing
An alert: the reading and threshold that fired it, and the timeline of notification, claim and recovery.
API response over 2 sapi.example.com/health timed out three times in a rowRecovered
Reading
2.4 s
Threshold
2 s · 5 min
Check
api.example.com/health
  1. Fired: response took 2.4 s09:12
  2. Notification sent09:12
  3. Claimed by the on-call member09:18
  4. Recovered: response took 180 ms09:31

Maintenance windows, retries and thresholds keep alerts quiet.

Inside a maintenance window, collection continues, but problems do not alert and do not count against the SLO; cancel the window and alerting resumes at once. Web checks can retry before they call a run unhealthy, and can mark slow responses. Template thresholds can be tuned per machine, and a status page component can ignore alerts below a chosen severity.

Maintenance window

  • One-time, daily, or weekly, set by duration
  • Can cover the whole project, including machines added later
  • Collection continues; alerting and SLO counting pause
  • Canceling the window resumes alerting immediately

Stop collection

  • No new metrics and no alerts
  • History is kept
  • Collection must be resumed by hand
  • Deleting the machine removes its history and alerts

You set the target and what counts as unavailable; the report measures the rest.

Each project has one SLO. Set a target below 100%, a period, the severity at which an alert counts as unavailable, and the hours the promise covers. The report gives measured availability, uptime, and downtime, the error budget left or overspent, and a breakdown by machine. Downtime inside maintenance windows is excluded.

You set

  • Target availability below 100%, with up to four decimal places
  • Period: daily, weekly, monthly, quarterly, or annually
  • The severity at which an alert counts as unavailable
  • 24/7 or set hours, in the project time zone

The report gives

  • Measured availability, uptime, and downtime
  • Error budget left, or the time already overspent
  • Availability broken down by machine
  • Downtime excluded by maintenance windows

The state of each service, written for the people using it.

A component is one row on the public page, such as sign-in or payments, not a machine name. Bind machines or web checks to a component and its status follows their alerts: high and disaster become a major outage, average becomes a partial outage, warning becomes degraded performance, and anything below the chosen floor leaves the status unchanged. You can also publish notices and schedule maintenance in advance.

On the public page

  • Component status: operational, degraded performance, partial outage, major outage, or under maintenance
  • Incident notices with impact and progress
  • Planned maintenance announced in advance
  • Availability bars over 30, 60, 90, or 180 days
  • Page theme, brand color, support link, and footer
  • Not indexed by search engines by default

Only in the Console

  • Machine names and metrics
  • Alert severity and trigger conditions
  • Handling notes and assignments
  • Which machines and checks back each component
A public status page: overall state, three components and one bar per day of uptime.
status.example.comAll systems operational
  • Website30-day uptime
  • API30-day uptime
  • Background jobs30-day uptime

Also included

  • Host metrics

    After a template is bound, the agent collects CPU, memory, disk, network, and process state. In active mode the machine connects out, so no inbound port is needed for collection.

    Active mode opens no inbound ports

  • Monitoring templates

    Beyond the operating system template, bind Systemd, Docker, Nginx, PHP-FPM, certificates, S.M.A.R.T., NVIDIA, ICMP, and Proxmox VE as they apply.

    One operating system template per machine

  • Enrollment and key

    Registering a machine produces an agent configuration and a key. The key is returned once; if it is lost after collection starts, rotate it.

    The key is shown once

  • Web checks

    Request several addresses in order, with steps sharing one session; verify status codes and response content, and follow redirects when needed.

    Every 60 seconds by default

  • Retries and thresholds

    A run is unhealthy only after consecutive failures reach the retry count. A response time threshold marks responses that are too slow.

    Consecutive failures before an alert

  • Alert handling

    Alerts queue by severity and can be claimed, assigned to a member, annotated, and closed; close reasons include duplicate and false positive.

    Close with a reason

  • Timeline

    Firing, recovery, acknowledgment, assignment, following, notes, closure, and reopening all go on the same timeline.

    Append only, never rewritten

  • Notifications

    Alerts reach project members in the inbox and by email, or through Feishu and WeCom group bots, Bark, and webhooks.

    Mute or raise the floor per type

  • Maintenance windows

    Collection continues inside a window, but problems do not alert and do not count against the SLO; a window can cover the whole project.

    One-time, daily, or weekly

  • SLO and error budget

    Set a target, period, unavailable severity, and promised hours; the report gives measured availability, the error budget and a breakdown by machine.

    One per project, up to four decimals

  • Public status page

    Components, groups, notices, and planned maintenance; a component can change status automatically from machine or web check alerts.

    Availability bars over 30 to 180 days

  • Custom domain

    Point a domain such as status.example.com at the platform by CNAME; once it verifies, a certificate is issued.

    CNAME verification before the certificate

Pricing

Free for now. A top-up of at least US$1 is still required before using Leaflow.

How every product is billed

Details

Collection
Active (no inbound ports) or passive (the agent port must be reachable, 10050 by default)
Systems
Linux and Windows, by the operating system template bound to the machine
Templates
Linux, Windows, Systemd, Docker, Nginx, PHP-FPM, certificate expiry, S.M.A.R.T., NVIDIA GPU, ICMP Ping, and Proxmox VE
Web checks
Every 60 seconds by default; timeout, retry count and response time threshold can be set
Alert severity
Not classified, information, warning, average, high, and disaster
Notifications
Inbox, email, Feishu and WeCom group bots, Bark, and webhook
SLO
One per project; daily, weekly, monthly, quarterly, or annual periods; target below 100% with up to four decimal places
Promised hours
24/7 or set hours, up to 21 windows
Status page
One per project; unpublished by default; shared address or custom domain by CNAME; availability bars over 30, 60, 90, or 180 days
Billing
Free for now; a top-up of at least US$1 is required before using Leaflow

Questions

Do I need to open inbound ports?

Active mode does not; the agent connects to the monitoring service. Passive mode has the platform connect to the machine, so its agent port must be reachable, 10050 by default.

Can I monitor another cloud or my own machines?

Yes. Any machine where the agent can be installed and reach the monitoring service can be enrolled. A machine without an agent can be checked with the ICMP template, and Proxmox VE can be collected through its API.

How often do web checks run, and can I change it?

Every 60 seconds by default. The interval, timeout, retry count, and response time threshold can all be changed. Checks run from the monitoring service, so nothing is installed on the target site.

What is the difference between a maintenance window and planned maintenance?

A maintenance window suppresses internal alerts and keeps that time out of the SLO. Planned maintenance is the notice on the public status page; affected components show as under maintenance and availability is not reduced. The two are usually created together.

Will alerts be sent more than once?

Bursts of alerts about one machine are summarized on outbound channels, while the inbox keeps every notification. Web checks wait for consecutive failures to reach the retry count, and maintenance windows suppress alerts.

Can an alert trigger a Shipping task?

Yes. Monitoring alerts arrive on EventBus as platform events. A Shipping event task can subscribe, filter with a CEL condition, and run on a cooldown; steps that need approval wait for you.

How is the SLO calculated?

Each project has one SLO. Choose a target, a period, and the severity that counts as unavailable, then measure availability over the promised hours. The report gives downtime and the error budget left or overspent, with downtime inside maintenance windows excluded.

How is it billed?

Monitoring is free for now. A top-up of at least US$1 is required before using Leaflow.

Get started in the Console.

Top up at least US$1 before first use. After that, each product is billed at its public price.

Get startedView pricing

Other products

All products