An automation is only as trustworthy as its worst day. Anyone can wire up scheduled AI agent automations to run while you're away — the harder problem is what happens when a run doesn't actually start, and nobody notices until the work it was supposed to produce simply isn't there. Influxx's Automations page was built around that harder problem: a first-class part of the app where scheduled agent work runs on its own, and where a failed run gets an obvious next step instead of a line buried in a log.
Automations Earned Its Own Page
For a while, "automation" inside a coding tool usually meant a rule you configured once and then had to trust blindly — you'd tell it when an agent should run, close the laptop, and hope. That's not good enough once agent runs are doing work you actually depend on: a refactor sweep, a nightly test run, a dependency bump, the kind of thing you'd otherwise nag a teammate to handle overnight. Once you're delegating real output to a schedule, you need somewhere to go check on it — not a toast notification you happened to miss, not a settings screen you forgot existed.
That's what the Automations page is: a real, navigable section of Influxx sitting alongside Tasks in the same sidebar, with its own back-and-forward history like every other major area of the cockpit. Two different kinds of scheduled work land there. The first is automations defined locally inside Influxx — rules you set up yourself, which Influxx checks on a short interval, roughly every sixty seconds, to see if anything is due to run. The second is jobs scheduled through an external automation companion service, reconciled into that same view. You don't get handed a second tool to remember to open; whatever's scheduled, from either source, shows up in one place.
Closing the Navigation Gap Between Tasks and Automations
Here's a concrete example of what "first-class page" has to mean in practice, not just on a slide. Tasks — Influxx's other major view for tracked, ongoing work — had proper browser-style back-and-forward navigation: dive into a task, click around, hit back, and land exactly where you expected. Automations didn't. That history had regressed, or in places had never really existed, so moving around inside Automations felt like a slightly different app than the one you'd just been using a tab over in Tasks.
On paper, that's a small inconsistency. In practice, it's exactly the kind of gap that tells a developer a page is an afterthought — and Automations is the page you open reactively, when something needs attention, which is the worst possible moment for the app to suddenly behave differently. We closed the gap deliberately, not as a courtesy to Automations specifically, but because a page where scheduled agent work lives, and where you go to investigate when something's wrong, has to behave exactly like everywhere else in Influxx. No exceptions, no corner of the app that's still catching up.
Scheduling Is Table Stakes
Checking roughly every sixty seconds for what local automations are due, and reconciling in whatever the external automation companion has scheduled, solves the part of automation that's easy to demo: agent runs firing on time, unattended, without you sitting there triggering each one by hand. That part matters. It's also the part every scheduling tool eventually gets right. It's necessary, but it has never been the hard part.
The hard part is what a developer actually needs to believe about a scheduled automation before they'll stop watching it manually. First, that it will run when it's supposed to. Second — the part that's much easier to skip when you're building this kind of feature — that when it doesn't run correctly, there's an obvious, immediate way to fix it. Not a log to dig through. Not a mental reconstruction of what the automation was even supposed to do in the first place. An obvious next action, sitting right where the failure is already showing up.
How a Scheduled Run Actually Fails
"Failed to start" isn't one failure mode — it's a few, and from the outside they all look the same: nothing happened.
- Dispatched, but never actually started: the automation fired on schedule, but the run itself never got off the ground — no agent process ever came up to do the work.
- Skipped for a missing tool: the automation calls for a specific CLI agent that wasn't available in the environment the run tried to execute in, so Influxx skips the run rather than silently substituting something else.
- Skipped for interactive authentication: some agent CLIs need a login prompt or an interactive authentication step, whether it's the first run or a session that's expired — something only a human can click through. An unattended run can't do that, so it's skipped instead of hanging indefinitely.
Before we built a recovery action for this, all three looked identical from a developer's side: nothing happened, and you had to be the one to notice. There was no local button, no shortcut back into motion — you'd spot the failed run and then have to manually reconstruct, from memory, what that automation was supposed to do, and go run it some other way yourself.
Rerun: The Same Path, Just Triggered for You
The fix we shipped is a one-click Rerun action that appears directly on a failed run. Click it, and Influxx dispatches that automation exactly the way it would if you'd opened it and started it by hand — same manual-run path, same everything. It isn't a separate, special recovery pipeline bolted onto the side of the product; it's the ordinary "run this now" mechanism, invoked automatically on your behalf, from the exact spot where you can already see the run failed.
That reuse was a deliberate choice, not a shortcut taken to ship faster. A dedicated recovery code path is one more thing to keep correct, one more place a fix has to land twice, one more way a "rerun" can quietly start behaving differently from what a manual run actually does.
"We had two options: build a purpose-made recovery flow for failed runs, or make Rerun call the exact same dispatch path a human uses to start that automation by hand. The second one means Rerun can never behave differently from clicking run yourself, because it isn't a different action — it's the same one, triggered for you. Fewer code paths doing the same job is fewer ways for the recovery button itself to become the thing that's broken."
— Daniel Kwon, Staff Engineer, Agent Orchestration at ETAPX
What Rerun Doesn't Protect Against
We'd rather be direct about a real gap than let a developer discover it the hard way: Rerun does not add backend idempotency protection. If you click Rerun, and in a shared setup a teammate who can see the same automation clicks Rerun on that same failed run around the same time, nothing stops both clicks from going through. You can end up with two runs of the same automation queued and executing, not one.
That's a known trade-off, not an oversight we're hoping nobody notices. Rerun exists to solve the much more common problem: a run silently failing to start, with no local way to recover it at all. Guarding against a near-simultaneous double click from two different windows is a real edge case, but a narrow one, and it wasn't worth holding back the recovery action itself while we solved for it.
"We'd rather tell developers exactly where the edges are than have them find out mid-incident. Rerun fixes the failure that actually happens constantly — a run that quietly never started, and nobody having a way to recover it without reconstructing the whole thing by hand. Two people clicking Rerun on the same run within a few seconds of each other is a real gap, but it's a narrow one, and it wasn't worth holding back the fix everyone needs just to fully close the rare one."
— Daniel Kwon, Staff Engineer, Agent Orchestration at ETAPX
One Place to Check, Not Two Habits to Build
The reconciliation between locally defined automations and jobs from the external automation companion matters for the same reason the rest of Influxx works the way it does: one cockpit, not five habits spread across five tools. If scheduled agent work only showed up in whichever system created it, you'd need to remember to check two places, in two different mental models, before you could actually trust that "nothing's overdue" meant nothing was overdue. Reconciling both into a single Automations view means there's exactly one place to look, and exactly one failure state worth designing a recovery action for.
"I've got a handful of agents doing overnight work — dependency bumps, a nightly test sweep, a docs pass — some scheduled right inside Influxx, some coming through our external scheduler. Before, I needed two tabs open just to feel sure nothing had silently died overnight. Now it's one page, and if something didn't run, there's a button sitting right there instead of me trying to remember what that job was even supposed to do."
— Priyanka Desai, senior backend engineer and Influxx user
Recovery Is the Feature, Not an Afterthought to It
It's easy to design scheduling and treat failure handling as leftover work — an error toast, a log line, something a sufficiently diligent developer can go dig up on their own time. We built Automations the other way around: a failed run is a first-class state with its own obvious action, sitting exactly where you'd already be looking, not a forensic exercise you have to volunteer for. That's the same instinct that shapes how we think about running agent CLIs generally in Influxx — visibility into what actually happened matters just as much as making the thing run in the first place.
Frequently Asked Questions
What counts as an "automation" inside Influxx?
Two things, reconciled into one view: automations you define locally inside Influxx, which the app checks roughly every sixty seconds to see if anything is due, and scheduled jobs coming from an external automation companion service. Both show up on the same Automations page, so you never have to check two separate systems to know what's scheduled.
How often does Influxx check whether a local automation is due to run?
Roughly every sixty seconds. That interval is short enough that a scheduled automation fires close to its intended time without Influxx needing to poll aggressively in the background.
What happens if a scheduled automation fails to actually start?
It shows up on the Automations page as a failed run, with a one-click Rerun action right on it. Rerun dispatches the automation through the same manual-run path you'd use to start it by hand, so recovering from a failed unattended run doesn't require reconstructing what the automation was supposed to do.
Why would a scheduled run fail to start in the first place?
The most common reasons are the run being dispatched but never actually starting, the run being skipped because the CLI agent it needed wasn't available in that environment, or the run being skipped because it required an interactive authentication step that isn't possible in an unattended context.
If I click Rerun twice, will it queue two runs?
It can. Rerun doesn't currently add backend idempotency protection, so if you or a teammate click Rerun on the same failed run in two different windows around the same time, both clicks can go through and queue duplicate runs of that automation. It's a known trade-off, not a hidden one, and worth keeping in mind in a shared setup.
Does the Automations page navigate the same way as the rest of Influxx?
Yes. Automations has the same back-and-forward navigation history as other major sections like Tasks, so moving into a run's detail and back again works the way you'd expect anywhere else in the app.
None of this makes scheduled agent work infallible — tools go missing, authentication sessions expire, runs occasionally just don't start, and that's not going to change. What changes is what happens next: instead of a developer noticing a gap days later and piecing together what should have run, there's a page built to surface exactly that failure with an obvious button to fix it. Scheduling gets an agent to show up on time. Recovery is what actually earns the trust to stop watching it.
