Monitors

A monitor is an endpoint configuration and the checks Stazus runs. Each check evaluates availability, response content, and latency from your settings.

Create a monitor

1. Open a project.
2. Select New endpoint.
3. Enter an endpoint name and URL.
4. Set the HTTP method and expected status code.
5. Set the interval and timeout.
6. Configure response matching and latency alerting when needed.
7. Save the endpoint.

The endpoint name must be unique in its project. The URL must use http:// or https://.

Request settings

Choose a read-only service path. Stazus supports GET, HEAD, and OPTIONS. It does not schedule POST, PUT, PATCH, or DELETE requests because a monitor must not change the target service. The upgrade disables existing endpoints that use an unsafe method. Change those endpoints to a read-only health route before you enable them again.

Add request headers when the route requires authentication or content negotiation. The request payload must be valid JSON when you provide one.

Verify destination ownership

Stazus creates each monitor in the disabled state. Open the endpoint edit page and copy its challenge token. Your service must return that token from the listed HTTPS URL. Return it as the plain-text response body or in a Siftr-Verification response header.

Select Verify destination after you deploy the challenge. A successful verification does not enable the monitor. Enable it and save the endpoint when you are ready. If you change the hostname, Stazus creates a new challenge and disables the monitor until you verify the new hostname.

Each team can schedule up to two monitor requests per second and transfer up to 64 MiB per hour. The SQLite installation accepts up to five scheduled monitor requests per second across all teams. Stazus blocks an endpoint enable or interval change that would exceed either schedule rate. It also blocks a check when the team exceeds the bandwidth budget.

Response expectations

Every endpoint has an expected HTTP status code. You can also choose how Stazus checks the response body.

Avoid exact matching for responses that contain timestamps, generated IDs, or other changing values. Use Contains or JSON subset when a stable marker is enough.

Schedule and timeout

The interval controls when scheduled checks run. It must be at least 30 seconds. The timeout is the maximum wait time. It must be at least 1 second and shorter than the interval.

New or re-enabled endpoints can start up to half an interval later. This spreads requests over time.

Latency detection

Latency monitoring can be off, observed without incidents, learned from checks, or compared with a fixed threshold.

• Off — do not evaluate latency anomalies.
• Shadow — classify anomalies without opening incidents.
• Auto — compare checks with a learned latency baseline.
• Fixed — use a threshold you define in milliseconds.

Start in shadow mode when you do not know normal performance. Use automatic or fixed detection after you understand the endpoint’s usual latency.

Read latency alerting before you use automatic detection in production.

Maintenance

Schedule a maintenance window when planned work would create false alerts. You can cover the whole team, one project, or one endpoint. Checks continue to provide evidence. Stazus marks covered checks as suppressed and excludes them from automatic incidents, latency learning, and uptime statistics.

Read maintenance windows for the full procedure.

Disable a monitor

Clear Enabled when you need to stop scheduled checks. Stazus skips disabled endpoints. A disabled endpoint keeps its configuration and recorded history.

Use a maintenance window when you still need check evidence during planned work.

Next steps

• Read checks and results
• Configure latency alerting
• Manage maintenance windows