The run log

Every time a rule matches an event, Tenvara records a run. The run log is where you check that rules behave, find out why one did not, and retry one that failed.

Reading the run log#

Go to Settings > Run log. Each row shows the Outcome, the Rule and the version that ran, what it was About (an alert, ticket, device, customer or schedule), the Customer, What happened (the triggering change, the result or the error), how long it Took and When.

Filter by Outcome, Rule, Customer and When, choose a date range with Dates, or type to search. The Views picker goes straight to Failed runs, runs stopped by Loop protection, Dry runs and runs Waiting. A rule's own runs are one click away from its ... menu (Its run log), a customer's runs are on the Automation tab of the customer page, and a device's recent runs are in the Automation block on the device page. A link to the run log can carry a ticket, project, rule or device, so it opens on just those runs.

The newest runs load first; Load older runs fetches the next lot from the server.

Export runs#

Export downloads every run matching the filters and dates as CSV or Excel, with the rule's version, the step that failed and the reason. Use it to show a customer what automation did for them, or to look for patterns in failures.

Outcomes#

A run's page#

Click a run to open it.

• The header shows the rule and version, what it was about (with a link), the customer, when and how long it took.
• What it did lists each action in order with its detail (for example "Ticket #1547"), how long it took and Done, Failed, Skipped or Would do, with the error or reason where there is one.
• Conditions lists each condition with the value it saw.
• What happened describes the event, and says when it was Caused by another rule acting before it.
• The rule as it ran shows that version of the rule, with who made it and when.

Changes a run made, and Undo#

Every Microsoft 365 change a step makes is listed on the run under its step: what changed, on which user, group or mailbox, its status (done, waiting for Microsoft, waiting for approval, failed or undone) and, where Tenvara knows them, the values before and after. Undo sits beside each change that can be undone. It runs as the person pressing it, with their own Microsoft 365 permission (undoing a destructive or high-risk change is for administrators), and is in the audit log. A change sent for approval shows what the approval decided, and a change undone from the tenant's own change log shows as undone here too. See Microsoft 365 steps and the leaver bundle.

When a rule fails#

A rule's owner is always told when it fails or is stopped by loop protection (at most once an hour per rule). The General tab of Settings > Channels, under When a rule fails, tells others too:

• Also tell these people, Everyone with a role and Teams or Slack channels.
• Critical rules page on-call: when a rule marked critical fails, on-call is paged through the default escalation policy.
• Daily digest to administrators: every failed and stopped run of the day before, in one message, sent at the time you choose.

A rule can name its own people instead, and be marked Critical, with Tell on failure in the builder. Administrators also see the Failing rules, last 7 days on Home, critical ones first.

Retrying a run#

A failed or stopped run has a Retry button. Retry runs the rule's current version again on the same subject, from the start, without checking the conditions again (they held when it first ran). Fix the cause first: a webhook address, a script, the owner's permissions.

Loop protection#

Rules can set each other off: a rule that adds a note fires "A ticket is updated", which can match another rule, which changes the ticket again. Every run carries the chain of runs that led to it, and Tenvara stops a chain that goes round in circles.

• A run is stopped when it is caused by more rules in a row than the limit (3 by default).
• A rule never runs twice for the same alert, ticket or device in one chain.
• A rule runs at most a set number of times an hour for one subject (10 by default).
• Stopped runs say Stopped by loop protection and why, for example "This rule already ran for this ticket earlier in the same chain of events".
• If a rule is stopped too often in an hour (3 times by default), it raises an alert and its owner is told.

A stopped run usually means two rules undo or repeat each other's work. Tighten a condition on one of them or end one with Stop.

Stalled runs#

If a run loses its worker (a server restart in the middle, for example), Tenvara notices: a run still Running after 30 minutes is marked failed, and you can retry it; a run still Queued after 10 minutes is queued again. Both times can be changed under Timings and limits in the settings below. A run is claimed before anything happens, so it never runs twice.

Settings for runs#

Administrators set these on the General tab of Settings > Channels:

The same page holds the paging defaults (see On-call rotas and paging) and Timings and limits: how long before a running rule counts as failed and a queued one is sent again, how old a device reading may be for a metric rule, how long the acknowledge links in pages work, and how many devices one software deployment from a rule may reach.

SLA warnings are part of each SLA policy: when a target warns, who is told, and whether the ticket is reassigned, raised in priority or paged. Open SLA policies on this page takes you there, and rules still hear the SLA warning and SLA breach changes. See SLA policies and escalations.