HowlOps
Concepts

Platform capability map

A concise, current map of what HowlOps monitors, verifies, routes, escalates, coordinates, and publishes, with links to the detailed behavior.

On this page

HowlOps connects detection, human response, and customer communication. This page is the shortest route to understanding what the product handles today. Follow the links for exact configuration and edge-case behavior.

Feature availability and limits can depend on your plan or an optional capability. See Plans & capabilities for entitlements. This page describes product behavior, not a promise that every capability is included in every plan.

The complete operating loop

Detect

Runs HTTP/S, ping, TCP and DNS checks, watches for a scheduled heartbeat, or accepts an external alert. You control: target, check type, interval, regions, validation and maintenance. See Monitors and Heartbeats.

Verify

Records regional evidence, retries when configured and applies confirmation thresholds. You control: required failures, regional quorum, degraded threshold, recovery period and suppression policy. See How we verify outages.

Open one alert

Deduplicates repeated checks or external fingerprints into one active alert and retains the evidence. You control: severity, labels, per-region behavior, repeat interval and failure screenshots. See Alert & incident flow.

Route and escalate

Evaluates routing rules, selects a policy, resolves the on-call person and advances until acknowledgement. You control: rule order, targets, schedule layers, overrides, delays, repeats and channel order. See On-call & schedules and Escalation policies.

Coordinate

Keeps acknowledgement, ownership, evidence, notes, roles, updates and resolution on one timeline. You control: promotion rules, severity, responders, notes, public updates and postmortem. See Incidents & severities and Incident response & ChatOps.

Communicate and recover

Updates connected status surfaces, resolves recovered alerts and sends the all-clear. You control: published components, subscribers, maintenance, public wording, custom domain and postmortem visibility. See Status-page incident response.

Monitoring and signal sources

HowlOps can create a signal from:

  • HTTP/S checks with methods, headers, request bodies, authentication, expected status codes, keyword matching, SSL checks, domain-expiry checks and optional failure screenshots.
  • Ping, TCP and DNS checks.
  • Heartbeats for cron jobs, backups, queues and other scheduled work.
  • Incoming integrations such as Prometheus Alertmanager, Grafana, Datadog, CloudWatch and generic webhooks.

Native monitors carry HowlOps check evidence. Incoming alerts carry the evidence and labels provided by their source; HowlOps does not invent a time series or screenshot for an external event.

Paging and on-call

Routing rules can match the signal source, monitor type, tags, labels or severity. The first matching rule selects a policy. If no rule matches, the monitor policy and workspace default are evaluated before falling back to broadcast delivery.

An escalation policy can target people, teams, schedules and channels over timed steps. On-call schedules support layers, rotations, temporary overrides, swaps and cover. Each user can order their personal channels so a page can progress from push to email, SMS, or voice. Acknowledging or resolving stops the remaining escalation; a bounded silence pauses it.

Alerts are not the same as incidents

An alert is the active signal that drives notification and escalation. An incident is the coordination record for work that needs shared ownership, updates or a postmortem. Paging starts from the alert; promotion to an incident does not page the same event again.

This separation lets a team receive actionable alerts without turning every signal into a major incident. Promotion rules can create incidents automatically for critical or matching events, and responders can promote an alert manually when coordination becomes necessary.

Integration, access, and governance

The operating loop is not isolated from the rest of your stack:

  • Inbound integrations accept alerts from monitoring and cloud tools. Outbound integrations deliver notifications or create work in connected systems.
  • The REST API, webhooks, hwl CLI and MCP surface support automation without replacing the permissions enforced by the workspace.
  • Workspace roles, team scopes and the audit history make operational changes attributable.
  • SAML and OIDC support single sign-on; SCIM supports account lifecycle provisioning. MFA and passkeys are available for direct authentication.
  • Preview-first importers show what supported providers can migrate before HowlOps creates anything. Exact source coverage is listed in Importer capabilities.

These capabilities are plan-dependent where the plan reference says so.

Measurement and learning

Check history, response-time history, uptime, latency, SLA and SLO views explain service reliability. Incident counts, acknowledgement and resolution timing explain the response. CSV reports and postmortems make both histories portable without treating generated metrics as a substitute for a human root-cause analysis.

Automatic behavior and team decisions

HowlOps handles automatically
  • Run checks and retain regional evidence
  • Confirm failures using configured thresholds
  • Deduplicate repeated signals
  • Select the first matching route
  • Resolve the current on-call target
  • Advance escalation until acknowledgement
  • Resolve recovered alerts and send the all-clear
Your team decides
  • Regions, intervals and validation rules
  • Confirmation, quorum and recovery settings
  • Severity, labels and repeat behavior
  • Routing conditions and policy priority
  • Schedule layers, rotations and overrides
  • Targets, delays, repeats and channel order
  • Status-page wording and public visibility

Where to start

Was this page helpful?