InfraNestInfraNest
Automation rules

Check your automation runs

Once a rule is live, InfraNest records every time it runs — so you can confirm it's working and see exactly what each action did.

Updated October 30, 20263 min read

This article is for anyone who wants to check whether their automations are working as expected — useful when you're setting one up, or when something didn't fire the way you thought it would.

#Overview

  • Every automation rule keeps a record of its runs, so you can confirm it's working and see exactly what each action did.
  • You can check a rule before saving it, test it on demand once it's saved, and look back through its run history whenever something seems off.
  • Guardrails like Cooldown and failure detection help keep rules from misbehaving.

#Preview a rule before saving

  1. While building a rule, click Preview (dry run) to see what it would do, using a real recent example from your account. This is a safe dry run — it doesn't actually perform the actions.
  2. For any step that uses a connected service, such as GitHub or PagerDuty, the preview names the connection it would use.
  3. For Create GitHub issue, the preview goes further — it shows the repository and the title with your placeholders filled in, and checks the connection can actually open an issue there. If it can't, the step shows as failed and explains why, and nothing is created.
  4. If a placeholder comes out empty for the example, it's listed under the step. A blank there usually means that part of the title or message would be missing, so double-check it before you save.
  5. Placeholders that only the real event can fill in (like the number of days before a domain expires) won't show in the preview, since the example doesn't have that data yet.

#Test a saved rule

  1. Open the rule you want to check.
  2. Click Test run to run it on demand and see the outcome, without waiting for the real event to happen.
  3. Each step shows what it would have done, with the same details and empty-placeholder warnings you'd see in the preview.

#Check run history

  1. Open the rule you want to review.
  2. Look at its recent Runs.
  3. Each run lists its Actions as steps, in order, along with whether each one succeeded, failed, or was skipped — including the output or error message.
Check your automation runs
  1. If a rule waits before alerting again (for example, "Monitor down → wait, then escalate"), it can stop early if someone already acknowledged the issue or it recovered on its own. In that case, the run shows as Skipped, and the wait step explains why — for example, Stopped: {name} acknowledged it. Nothing after the wait step was sent.
  2. The All automations list also shows Runs — how many times each rule has run in total.

NoteRun history is kept for 90 days. The details of a run — including the event that started it and what each step sent — are only visible to members whose role can edit automations, since they may contain text from other tools, like a GitHub comment. Everyone else can still see whether a run worked and any error message.

#Guardrails

  • Cooldown — if a rule has a cooldown set, it won't run again for the same thing until the wait time passes, so a burst of events about one domain or monitor can't spam it. Other domains and monitors aren't affected.
  • Rules that keep failing are flagged as Auto-disabled after repeated failures, so you can fix or disable them.

TipEvery run is also recorded in your Audit Log, so you have a second place to check what happened and when.

Related articles

Try this in your own account

Connect one provider and work through these steps against your own infrastructure.

Free plan · No credit card required · Set up in minutes