Host and service alert log entries from the last hours hours, newest first.

Each entry resolves its host and service name, costing one extra API request per entry.

Detailed status of a host plus the services running on it.

hostname matches as a substring, so several hosts can come back; each entry carries its own services. Use list_services_by_state instead when you want failing services across the whole estate rather than one host's full inventory.

A host present in the configuration but not yet known to the monitoring engine is returned with monitored: false and no check results. This differs from the host not existing, which raises instead.

Services currently in a given state. Pass state="critical" for the usual "what is broken" question.

Before reporting an entry as a new incident, check list_service_acknowledgements and list_service_downtimes: a problem already acknowledged or inside a downtime window is known work.

Health of the monitoring engine itself: how many hosts and services it watches, and its check throughput and latency.

Relevant when many unrelated checks fail at once: high check latency or a collapsed check rate means the engine is behind and its results are stale, which looks identical to a real outage.

Scheduled and running downtimes for hosts. Leave hostname empty for all hosts. Set only_active=True for downtimes running right now, rather than also those scheduled for later.

Scheduled and running downtimes for services. Leave hostname/servicename empty for all services. Set only_active=True for downtimes running right now.

Acknowledgement history for one host: who acknowledged a problem, when, and with what comment.

Per host only - openITCOCKPIT exposes no estate-wide acknowledgement list. To find out whether current problems are already handled, take the hosts from list_services_by_state and call this for each one.

Acknowledgement history for one service: who acknowledged a problem, when, and with what comment.

Per service only - openITCOCKPIT exposes no estate-wide acknowledgement list.

List host groups with their name and description. Use this to find a group's exact name before filtering hosts or services by it.

List service groups with their name and description. Use this to find a group's exact name before filtering by it.

List service template groups (named groups of service templates, used e.g. to bulk-apply services to hosts).

Find monitoring commands (check, notification and event-handler commands) by name. An instance holds hundreds; pass name_filter with a substring to narrow the result.

Find host templates (reusable check/notification configurations for hosts) by name. Pass name_filter with a substring to narrow the result. get_allowed_elements_for_container reports which templates a specific container accepts.

Find service templates (reusable check/notification configurations for services) by name. An instance holds hundreds; pass name_filter with a substring to narrow the result.

Find contacts (people who can be notified) by name. Pass name_filter with a substring to narrow the result.

List contact groups (named groups of contacts used for notifications).

Get the organizational structure (containers: tenants, locations, nodes) starting at the given container, including which hosts, host groups and service groups live directly under it. Leave container_name at 'root' for the top-level structure.

Individual check executions for a host, newest first: output, latency and execution time per run.

Returns one row per check execution. list_host_state_changes covers only the points where the state changed.

Individual check executions for a service, newest first: output, latency and execution time per run.

Returns one row per check execution; list_service_state_changes covers only the points where the state changed. A rising executionTime before a failure indicates a timeout or resource exhaustion, an instant failure a configuration, auth or service-down condition.

Only the entries where a host's state changed, i.e. the timeline of an incident rather than every check run.

Only the entries where a service's state changed. Shows when it broke and whether it is flapping.

Software installed on a host, from the openITCOCKPIT agent's inventory. OS is auto-detected (Linux, Windows, macOS).

A host carries hundreds to thousands of packages. Pass name_filter to search by package name, or only_updatable=True for just the outdated ones. For updates across the whole estate use list_pending_updates or list_pending_security_updates.

A host with no agent inventory at all raises, rather than returning zero rows.

Hosts with pending security updates, with the package names and versions for each.

Shorter than list_pending_updates and usually the relevant one. Naming each package costs one API request, so max_packages_per_host caps how many are resolved per host; the update count itself is always exact.

Hosts with any pending updates, security or not, with package names and versions.

Covers all updates, not only security ones, and is correspondingly larger. Naming each package costs one API request, capped by max_packages_per_host.