Is there a way to create a downtime in the past?

JavierVilarroig · September 3, 2025, 8:03am

We are producing an incident report from IcingaDB postgre database. A piece of data that we want to include in the report is if the incident was a planned downtime or not.

The report seems OK and all the relevant data is there.

But I have already a couple of times where the operators forget to create the downtime before starting a maintenance intervention. I will like to be able to create that downtimes to make the database fully consistent with reality.

Through the regular icingaweb interface or trough the API is not possible to create a downtime in the past.

Is there any way to create a downtime in the past?

Thanks in advance

Javier Vilarroig

bberg · September 3, 2025, 9:13am

So do you want to check if there has been a downtime in the past? Or do you want to create that downtime after it has happened, just to have it look like there would have been a downtime if your operators would have created that downtime?

JavierVilarroig · September 3, 2025, 9:28am

I want to create the downtime after it has happened.

The written procedure is start a downtime in case of a planned/controlled intervention, like installing a secpatch, but I sometimes they forget. Errare humanum est.

moreamazingnick · September 4, 2025, 4:57am

you cant do it via api but here is one idea:

here is the sla function:

github.com/Icinga/icingadb

schema/pgsql/schema.sql

a25e2c2d9


      
          -- The enum values are ordered in a way that event_type provides a meaningful sort order for history entries with
          -- the same event_time. state_change comes first as it can cause many of the other events like trigger downtimes,
          -- remove acknowledgements and send notifications. Similarly, notification comes last as any other event can result
          -- in a notification. End events sort before the corresponding start events as any ack/comment/downtime/flapping
          -- period should last for more than a millisecond, therefore, the old period ends first and then the new one starts.
          -- The remaining types are sorted by impact and cause: comments are informative, flapping is automatic and changes
          -- mechanics, downtimes are semi-automatic, require user action (or configuration) and change mechanics, acks are pure
          -- user actions and change mechanics.
          CREATE TYPE history_type AS ENUM ( 'state_change', 'ack_clear', 'downtime_end', 'flapping_end', 'comment_remove', 'comment_add', 'flapping_start', 'downtime_start', 'ack_set', 'notification' );
          
          CREATE OR REPLACE FUNCTION get_sla_ok_percent(
            in_host_id bytea20,
            in_service_id bytea20,
            in_start_time biguint,
            in_end_time biguint
          )
          RETURNS decimal(7, 4)
          LANGUAGE plpgsql
          STABLE
          PARALLEL RESTRICTED
          AS $$

it includes “FROM sla_history_downtime” and it uses downtime_start and downtime_end.

so we look at this table:

CREATE TABLE sla_history_downtime (
  environment_id bytea20 NOT NULL,
  endpoint_id bytea20 DEFAULT NULL,
  object_type checkable_type NOT NULL,
  host_id bytea20 NOT NULL,
  service_id bytea20 DEFAULT NULL,

  downtime_id bytea20 NOT NULL,
  downtime_start biguint NOT NULL,
  downtime_end biguint NOT NULL,

  CONSTRAINT pk_sla_history_downtime PRIMARY KEY (downtime_id)
);

and here you can insert anything you want. every bytea20 column is stored in binary so you need some hex2bin function to have it readable in your code.

if you need the downtime in icingaweb2 as well you will need to add an entry here as well: