openITCOCKPIT

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

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.

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, servi…

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.

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

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

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.

Remove the acknowledgement of a host or service problem, so it notifies again. Says whose acknowledgement it was, and for a host how many of its services stay acknowledged. Waits until the engine shows it.

Run the check of a host or service now instead of at its next interval, for example after a fix. Waits for the new result and returns the state it gives.

Put a host or service that was taken out of the monitoring back in. A host brings its services back with it. It is checked again from the next configuration export.

Put a host or service into a scheduled downtime, so it stops alerting during planned maintenance, now or later. It is recorded under the user asking. A host's services are covered only with with_services. Waits until the downtime shows.

Take a host or service out of the monitoring without deleting it: it keeps its configuration and history but is no longer checked and no longer alerts. A host takes its services with it. Takes effect with the next configuration export. Use resume_monitoring to bring it back.

Update an existing contact, identified by its exact name. Read-modify-write, like update_service and update_host: it reads the contact, applies `fields` and resends all of it, so a field you leave out keeps what it has. A contact has no template, so nothing is inherited and no field accepts null. `fields`, all optional: - scalars: description, email, phone, user_id, host_notifications_enabled, service_notifications_enabled, notify_host_recovery/down/unreachable/flapping/downtime, notify_service_recovery/warning/unknown/critical/flapping/downtime, host_push_notifications_enabled, servic…

Update an existing contact group, identified by its exact name (a contact group's name IS its container's name - there is no separate name column). Read-modify-write, same pattern as the other update_* tools. A contact group's own container, meaning its name and parent, cannot be changed here; only `description` and its member contacts. `fields` (all optional): - description: plain text. - contact_names: replaces the full set of member contacts. Must be non-empty, openITCOCKPIT enforcing at least one member on every save, and every name must be visible from this group's fixed parent cont…

Update an existing host, identified by hostname. Read-modify-write, not a partial PATCH: it reads the host's current values, applies `fields` (plus container_name) on top and resends all of it, so a field you leave out keeps what it has. Inheritance works as in update_service: a value equal to the hosttemplate's is stored as inherited (null), a differing one as this host's override. To hand a field back to the template, set it to null in `fields` rather than omitting it. Applies to description, check_interval_seconds, retry_interval_seconds, max_check_attempts, notification_interval_seconds,…

Update an existing service. Identifies the service by (hostname, servicename), not a raw id. Read-modify-write, not a partial PATCH: the edit endpoint expects the whole service on every save and blanks every field a partial payload omits. This tool reads the service's current values, applies `fields` on top and resends all of it, so a field you leave out keeps what it has. Inheritance is kept automatically: on every save the backend stores a value equal to the servicetemplate's as inherited (null) and a differing one as this service's override. Resending an unchanged value therefore creates …