community.general.timestamp callback – Adds simple timestamp for each header

Note

This callback plugin is part of the community.general collection (version 9.5.1).

You might already have this collection installed if you are using the ansible package. It is not included in ansible-core. To check whether it is installed, run ansible-galaxy collection list.

To install it, use: ansible-galaxy collection install community.general.

To use it in a playbook, specify: community.general.timestamp.

New in community.general 9.0.0

Callback plugin

This plugin is a stdout callback. You can use only use one stdout callback at a time. Additional aggregate or notification callbacks can be enabled though. See Callback plugins for more information on callback plugins.

Synopsis

  • This callback adds simple timestamp for each header.

Parameters

Parameter

Comments

check_mode_markers

boolean

added in Ansible 2.9

Toggle to control displaying markers when running in check mode.

The markers are DRY RUN at the beginning and ending of playbook execution (when calling ansible-playbook --check) and CHECK MODE as a suffix at every play and task that is run in check mode.

Choices:

  • false ← (default)

  • true

Configuration:

display_failed_stderr

boolean

added in Ansible 2.7

Toggle to control whether failed and unreachable tasks are displayed to STDERR (vs. STDOUT)

Choices:

  • false ← (default)

  • true

Configuration:

display_ok_hosts

boolean

added in Ansible 2.7

Toggle to control displaying ‘ok’ task/host results in a task

Choices:

  • false

  • true ← (default)

Configuration:

display_skipped_hosts

boolean

Toggle to control displaying skipped task/host results in a task

Choices:

  • false

  • true ← (default)

Configuration:

format_string

string

Format of the timestamp shown to user in 1989 C standard format.

Refer to the Python documentation for the available format codes.

Default: "%H:%M:%S"

Configuration:

pretty_results

boolean

added in ansible-core 2.13

Configure the result format to be more readable

When result_format is set to yaml this option defaults to True, and defaults to False when configured to json.

Setting this option to True will force json and yaml results to always be pretty printed regardless of verbosity.

When set to True and used with the yaml result format, this option will modify module responses in an attempt to produce a more human friendly output at the expense of correctness, and should not be relied upon to aid in writing variable manipulations or conditionals. For correctness, set this option to False or set result_format to json.

Choices:

  • false

  • true

Configuration:

result_format

string

added in ansible-core 2.13

Define the task result format used in the callback output.

These formats do not cause the callback to emit valid JSON or YAML formats.

The output contains these formats interspersed with other non-machine parsable data.

Choices:

  • "json" ← (default)

  • "yaml"

Configuration:

show_custom_stats

boolean

This adds the custom stats set via the set_stats plugin to the play recap

Choices:

  • false ← (default)

  • true

Configuration:

show_per_host_start

boolean

added in Ansible 2.9

This adds output that shows when a task is started to execute for each host

Choices:

  • false ← (default)

  • true

Configuration:

show_task_path_on_failure

boolean

added in ansible-core 2.11

When a task fails, display the path to the file containing the failed task and the line number. This information is displayed automatically for every task when running with -vv or greater verbosity.

Choices:

  • false ← (default)

  • true

Configuration:

timezone

string

Timezone to use for the timestamp in IANA time zone format.

For example America/New_York, Asia/Tokyo). Ignored on Python < 3.9.

Configuration:

See Also

See also

ansible.posix.profile_tasks callback plugin

You can use ansible.posix.profile_tasks callback plugin to time individual tasks and overall execution time with detailed timestamps.

Authors

  • kurokobo (@kurokobo)

Hint

Configuration entries for each entry type have a low to high priority order. For example, a variable that is lower in the list will override a variable that is higher up.