Why a host or service did or did not notify: its settings, contacts and state checked the way Naemon checks them - disabled, downtime, soft state, host down, state not subscribed, acknowledged, no contact - and the notifications sent recently. Use it for "why did I get no alert for web01" or "who gets notified for Backup on db01".

Find running and planned downtimes of hosts and services, by host, service or comment. Cancelled and expired ones are left out. Use it for "is web01 in maintenance" or "what is planned for tonight".

Find hosts by name, state, container or host group, and count them per state. For unreachable hosts it names the down hosts they sit behind. Use it for "which hosts are down" or "how many hosts does tenant X have". For how one known host is doing, use get_host_health.

Checks that cause noise and what to do about each: flapping services, the services that notified most, and problems that have lasted without anyone acknowledging them or scheduling a downtime. Use it for "what is noisy", "why do we get so many alerts" or "what should we clean up".

Find services by host, name, state, container, host group or flapping, and count them per state. Use it for "which services are critical", "what runs on host web01" or "which disk checks warn". For how one known service is doing, use get_service_health.

When a measured value reaches its warning or critical threshold, from a straight line through its history. Reports the rate of change, the date and how well the line fits, per metric of the check. Use it for "when will the disk on db01 be full" or "what is filling up".

List the host templates, contacts, contact groups, timeperiods, host groups, etc. that are actually visible from a given container - i.e. the values a Create* tool for that object_type would accept there. openITCOCKPIT restricts every such reference to the target container's own scope (the container plus its descendants, plus a few legacy tenant-wide exceptions); values outside that scope are rejected. Call this BEFORE a create call whenever you are unsure a name is visible in the target container, instead of guessing and retrying on error. object_type must be one of: host, hosttemplate, servicetemplate, hostgroup, contactgroup, servicetemplategroup, contact. For hostgroup/contactgroup/servicetemplategroup/contact, container_name is the intended parent container (the object being created doesn't have its own container yet) - the result always includes 'legal_parent_containers' (the container types allowed to hold that object type), plus a members list (contacts/servicetemplates/timeperiods) only if container_name already resolves to a legal parent. container_name defaults to the root container if not given.

How available a host or service was over a period, computed from its recorded state changes. Reports the percentage with and without agreed maintenance, and how long it spent in each state. Use it for "how available was shop01 last month" or "did we keep the SLA".

Whether the monitoring engine runs the configuration as it stands: when it was last exported, what was changed since, what is configured but not monitored yet, and whether an export is running or even possible. Use it before and after a configuration change.

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; without access to root that is the top-most containers you can see.

How one host is doing: state and since when, what likely explains a problem (a down parent, a downtime, an acknowledgement), which hosts depend on it, its services by state, and recent state changes. Use it for "how is web01", "why is web01 down" or "what does switch01 take down with it".

What a host or service carries, before you disable, delete or take it out of the monitoring: its services, the hosts that depend on it, and the groups, maps and reports that name it. Use it to say what a change would affect.

How a service is configured and where each value comes from: what it sets itself and what it follows its servicetemplate for. Field names are the ones update_service takes, so a value can be changed by the name it is reported under. It reports the configuration, never the current state or check results.

How one service is doing: state and since when, what likely explains a problem (its host down, a downtime, an acknowledgement), and recent state changes. Use it for "why is Backup on db01 critical".

What is broken and what is only a consequence: down hosts and the unreachable hosts and services behind them, the remaining unhandled service problems grouped by service, and what is already in a downtime or acknowledged. Use it first for "what is broken" or "give me an overview".

A handover of the last hours: problems that began, what someone acknowledged or put in a downtime, how many notifications went out, and what is still open from before. Use it for "what happened during the night shift" or "give me a handover".

What happened around a problem: when it began, whether it happened before and how long it lasted then, which other hosts and services failed in the same minutes, and which configuration changes and exports came before. Works on the current problem, or on the last one when the object is fine again. Use it for "why did web01 go down" or "has Backup on db01 failed before".

List templates, commands, contacts, groups or time periods by name, sorted by name, to find the exact name another tool needs. The total counts every match; items lists the first. Use it for "which service templates exist for disks" or "what is the host group of tenant X called".

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 find_pending_updates.

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

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

Covers every update by default; security_only narrows it to the security ones. Naming each package costs one API request, capped by max_packages_per_host; the update count itself is always exact.