Audit And History

Ordyn records operational events so administrators can understand what happened, when it happened, who initiated it, and which resource was affected.

The two main views are:

• Audit, for a cross-system activity log
• endpoint History, for the operational timeline of one endpoint

Both views are intended for investigation and accountability. They are not a replacement for support bundles when raw diagnostic records, logs, or task artifacts are needed.

Audit View

The audit view is the broad activity log for Ordyn.

It shows events such as:

• job, orchestration, and template changes
• job run and automation activity
• endpoint lifecycle changes
• package, script, file, OS image, and configuration profile changes
• service-client activity
• administrative changes such as roles, users, settings, licensing, and enrollment tokens

Each event shows a user-facing title, time, category, severity, actor, affected resource, and additional details when available.

Use the audit view when you need to answer questions such as:

• who changed this job, package, script, or policy
• when a service client connected or changed state
• which administrative action happened before an issue started
• whether a broader system event correlates with an endpoint problem

Endpoint History

Endpoint history is focused on one endpoint.

It is designed to answer the practical question: what ran on this endpoint, and what happened?

Endpoint history shows higher-level operational events instead of low-level transport messages. For job activity, this includes:

• when a job started for the endpoint
• when a job finished, failed, timed out, or was aborted
• when individual job steps started
• when job steps completed, failed, timed out, were skipped, or were aborted
• the job name and step name captured at the time of execution
• links back to the matching job history view when available

Use endpoint history before opening lower-level job or audit data. It is usually the fastest place to confirm whether a job reached a device, which step ran, and which step changed state last.

Timestamps And Ordering

Audit and endpoint history timestamps include millisecond precision for recorded events.

When several events happen in the same second, Ordyn keeps their order stable by using the recorded event order as a tie-breaker. This matters for fast job dispatch, where several steps can start or finish close together.

Some entries can display .000 milliseconds when no more precise timestamp is available. Their display order remains deterministic.

Stored Context

History entries keep user-facing names and relevant snapshots so they remain useful even if the original resource changes later.

For example, job history can keep:

• the job name used at execution time
• the step name used at execution time
• the actor name when available
• the endpoint target context
• status and failure information

This makes history useful after a job, script, package, or endpoint has been renamed. If the original resource is deleted, some links may be unavailable, but the stored name and event summary remain visible.

Searching And Filtering

The audit view can be filtered by resource type, endpoint, category, severity, event type, actor type, date range, and common resource-specific filters.

Endpoint history can be searched from the endpoint detail page and is naturally limited to that endpoint.

Use endpoint history when the investigation starts from one device. Use the global audit view when the investigation starts from a resource, user action, service client, or time window.

Retention

Audit events and endpoint history events have separate retention periods.

By default, Ordyn keeps both for 365 days:

Setting	Description
ORDYN_AUDIT_EVENT_RETENTION_DAYS	Number of days to keep global audit events. Defaults to 365.
ORDYN_ENDPOINT_HISTORY_RETENTION_DAYS	Number of days to keep endpoint history events. Defaults to 365.

Set either value to 0 or lower to disable pruning for that dataset.

Retention is based on the event time. When an event is older than the configured retention period, Ordyn removes it during scheduled cleanup.

Audit and history entries keep user-facing names and relevant snapshots while they are retained. This keeps the entries useful when the original job, script, package, endpoint, or service client has been renamed. If the original resource is deleted, links may be unavailable, but the stored event title, summary, and captured names remain visible until the entry is pruned.

Security Notes

Audit and history data can contain sensitive operational context.

Depending on the event, entries may show:

• hostnames and endpoint names
• user or requester names
• job names and step names
• package, script, file, and configuration names
• failure messages and status details
• service-client names and operational state

Ordyn avoids showing raw secret values in audit and history views. Even without plaintext secrets, the surrounding operational context can still be sensitive and should be treated as administrative data.

Access Scope

Endpoint history follows endpoint access: a user needs permission to read the endpoint before they can view that endpoint's history.

The global audit view is broader. It is available to super administrators and to users with read access to supported feature areas. Once a user can open the audit view, Ordyn narrows the visible events by endpoint visibility, endpoint group visibility, and readable feature area.

Current security caveat:

• endpoint-specific audit and endpoint history are the safest views for scoped operators
• global audit is best treated as an administrative or broad-operator view
• feature-area audit events may be visible based on feature permission rather than a single folder or endpoint
• avoid granting broad read permissions only to allow audit access unless the user may also see operational history for that feature area

For tightly scoped troubleshooting, prefer endpoint history or endpoint support bundles.

For organization-wide investigation, use the global audit view with fixed roles assigned only to trusted operators. See Access Control for how fixed roles and super admin access work.

Support Bundles

Audit and history views are interactive investigation tools.

Support bundles are the right tool when a case needs downloadable evidence, server logs, raw job records, instruction records, service-client logs, or endpoint diagnostics.

See Support Bundles for the available bundle types.