Plexara
What you will take away from this lesson
An automation that runs every ten minutes and starts failing at two in the morning has failed thirty times by the time anyone is at a desk. Thirty alerts is how a channel gets muted, and a muted channel is how the next real problem goes unseen.
Plexara treats the failing as one incident. This lesson follows a real one on the demo tenant from the first failed run to the recovery, and covers what each failure records about itself so the person who reads it in the morning knows whether to act.
Learning Objectives
- 01Explain why a failing automation is one incident: one failure message, silence while it keeps failing, and one recovery message.
- 02Read a recovery message: when the failing began, how long it lasted, how many runs failed, and the error.
- 03Name the operations channels a failing automation posts to, under Admin > Settings > Run failures.
- 04Know which failures alert and which do not: a scheduled or event run alerts, a run started by hand reports in its answer.
- 05Read a failure’s cause and whether a retry should help, and know what is retried within a run.
- 06Know that the agent is told about failing automations at the start of the next session.
Where this lesson sits
Lesson 604 said a failed scheduled run emails its owner and is never re-run on its own, and 608 covered the channels results go out on. This lesson puts the two together for the hours nobody is watching.
600 Series: Automations
- 601Do not spend AI on what a script can doThe automation gap, what integration platforms and laptop scripts each cost, and the division of labor: a script for the deterministic part, the model for writing it and for judgment.
- 602The agent writes the first scriptThe loop from a recorded draft through tests to the save, what a save requires, what validate and a dry run report, the dialect’s deliberate absences, the traps that fail a draft, and the script’s page in the portal.
- 603Outputs: feeds, reports, and dashboards that refresh themselvesOutput identity across runs, tables and documents, the semi-dynamic dashboard and its data region, the referencing pattern, version caps, and delivery to a bucket drop.
- 604Running it: by hand, from the portal, and on a scheduleFour triggers, the cadence builder, the pinned fire date, what a schedule guarantees, and the run history with every trigger, duration, output, and log.
- 605What a run may do, and the record it leavesThe authority a run carries, what a save refuses, why the language cannot reach out, the lifecycle, ownership and transfer, and the administrator’s view.
- 606Scripts as skills: the weekly review the agent runs on your businessThree scripts attached to one prompt, the agent running them and reading the outputs against the knowledge graph, and a weekly list of action items with the figures behind them.
- 607Events in: a webhook source, its table, and an automation that reads itCreating a source, presets for known senders, what a sender is told, the table that serves events from acknowledgement, compaction and retention, the Webhooks page and its alerts, and the two ways an automation reads events.
- 608Results out: notification channels and signed delivery to other systemsChannel kinds and who may send to them, sending from a session and from an automation, the delivery history and the retry rule, the JSON envelope a system routes on, signed requests, and delivery to another deployment.
- 609One run per event: an automation that answers each returnNaming a source, the event a run reads, the run history with each event id, bursts and arrival order, a failed event run that alerts and is not replayed, and when a scheduled batch fits better.
- 610A mailbox as a source: filing the mail other systems sendA mailbox Plexara reads, allowed senders and sender authentication, one row per message and a file per attachment, text marked external, a filing automation, and the limits: no OCR.
- 611When an automation fails at 2 a.m.One incident instead of a message per failure, the recovery message, the operations channel, causes and what is retried within a run, and the agent’s briefing at the next session.
The 600 series picks up the registered table from the 500 series and the prompt mechanics from the 400 series.
One incident, two messages
Six rules turn a run of failures into something a person can act on in the morning.
One incident, two messages
- 01
The first failed run opens the incident
A scheduled or event run that fails emails the automation’s owner and posts to the run-failure channels. The message names the automation, why the run failed, the head of its error, the tail of its log, and a link to the run.
- 02
Runs that keep failing send nothing
They are counted on the incident. An automation that fails every five minutes overnight sends one message, not dozens.
- 03
The first run that succeeds closes it
Scheduled or started by hand, the next successful run sends one recovery message: the run that succeeded, when the failing began and how long it lasted, how many runs failed, the error, and the run that began it.
- 04
Recovered means the latest run succeeded
It does not mean what the failed runs left undone was redone. That happens only when the automation redoes it, as a watermark that was never moved does, and the message says so.
- 05
A run started by hand reports in its answer
Its failure is in the response the person or agent is already reading, so it sends nothing. A canceled run neither opens nor closes an incident; a run whose worker was lost counts as a failure.
- 06
The incident survives a restart
It is kept in the database, so a failure on one server pairs with the recovery on another, and an upgrade in the middle loses nothing.
Where the messages go
The owner is accountable for an automation and always gets the email. An operations team that watches a channel rather than each owner’s inbox is named once, for every automation.
Admin > Settings > Run failures
What the agent calls. This is the exchange the agent has with Plexara on your behalf, shown for the technical reader. You ask in plain language; you never type any of it.
PUT /api/v1/admin/settings/script-run-alert
{"channels": ["ops-events", "store-ops"]}
-> 200 {"channels": ["ops-events", "store-ops"],
"updated_by": "[email protected]"}An administrator names up to ten notification channels once, for every automation on the deployment. On the demo tenant they are the ops-events webhook channel, which a system routes on, and the store-ops email list, which people read. The owner’s email goes out either way. Naming a channel here is the authorization: the platform posts as itself, so no persona is consulted. The failure post and the recovery post carry different keys, so a channel’s repeat window never holds back the recovery that ends an incident.
The automation that failed
The incident below comes from a small automation written for this lesson, which depends on a feed that can stop.
acme-pos-feed-rollup-611, its main()
def main():
counts = window(run.fire_time)
if counts["events"] == 0:
fail("no point-of-sale events arrived in the ten minutes before %s; "
"the pos-sales feed has not published" % run.fire_time, retryable = True)
platform.result({"window_end": run.fire_time, "sales": ..., "returns": ...,
"revenue": ..., "stores": ...})
# window() counts the events, returns, revenue and stores the pos-sales
# table received in the ten minutes before the fire.A ten-minute roll-up of the point-of-sale feed, scheduled every ten minutes. An empty window means the feed did not publish, so the run fails, and says the failure is temporary with retryable = True: the condition is outside the script and the next run may not meet it. To produce the incident below, the simulator that feeds pos-sales was paused for half an hour.
The incident, run by run
With the feed paused, the next two scheduled runs found an empty window and failed. When the feed resumed, the run after them succeeded.
The incident on the demo tenant
What the agent calls. This is the exchange the agent has with Plexara on your behalf, shown for the technical reader. You ask in plain language; you never type any of it.
manage_script runs acme-pos-feed-rollup-611 fired trigger status cause retryable 09:20 schedule succeeded 09:30 schedule failed transient true -> incident opened, one post 09:40 schedule failed transient true -> counted, nothing sent 09:50 schedule succeeded -> recovered, one post posted to ops-events at 09:30 The scheduled automation "acme-pos-feed-rollup-611" failed The platform ran this automation on its schedule and the run did not finish. ... The script reported this failure as temporary, so there is nothing in it to fix yet; the next scheduled run will try again. You will not be emailed about further failed runs while it keeps failing; you will be emailed when a run of it next succeeds. posted to ops-events at 09:50 The scheduled automation "acme-pos-feed-rollup-611" recovered Run dpx_191406aa… of this automation succeeded. It had been failing since 2026-10-30 09:30 UTC, for 19 minutes, and 2 runs failed in that time. The first failed run was dpx_8539ce5b…. A succeeded run does not redo what the failed runs left undone unless the script does; check the runs if that matters. Cause: transient
Two runs failed and one message went out for them; the run that succeeded sent the second. The same pause tripped the webhook alert for a silent source on pos-sales, which posted a warning twenty minutes after the last event and a resolved post when the feed resumed, as 607 describes.
What a failure says about itself
Every failed run records its cause and whether running it again unchanged should succeed. That is the first thing the person reading the message needs to know: fix the script, or wait for the service.
What a failure says about itself
| Cause | What failed | Expected to pass next time |
|---|---|---|
| script | The script itself: an evaluation error, fail(), an argument a call refused, a step or time limit. | No |
| upstream | A service the script called timed out, dropped the connection, or answered its last call with a 5xx or 429 just before the script failed. | Yes |
| transient | The script said its failure was temporary, as the roll-up above does. | Yes |
| memory | The run held more than its memory budget. | No |
| worker lost | The servers running it kept stopping without a result until its take-overs were spent. | No |
| platform | The run’s session or its script could not be opened. | No |
| state conflict | Another run of the same automation saved its state first. The outputs stand. | Yes |
The platform never runs a failed run again on its own, whatever the cause: a run that already queried or wrote must not be replayed on the chance its last call was a passing fault. Expected to pass means the next fire, or whoever runs it again, should get past it. When three or more runs in a row fail on the same error, the owner’s email says the script needs correcting rather than waiting.
What is retried before a run fails
Some faults are over in seconds, and a run should not fail because of them. Three kinds are retried inside the run, within its deadline, before anything counts as a failure.
What is retried inside a run, before anything fails
- A service that says it is busy
- A 429, or a 502, 503, or 504 to a read, is waited out for the interval the service asked for, or 1, 2, then 4 seconds, and called again, at most three times and never past the run’s deadline. Each wait is a line in the log.
- A warehouse read that failed for a temporary reason
- Issued again after 1, 2, then 4 seconds, at most three times. A failure that is the script’s own, a missing column or a syntax error, is never retried.
- A run that could not start
- When the platform could not open the run’s session or read its script, the run goes back on the queue with a short backoff. Nothing it did is repeated, because it did nothing.
The agent hears about it too
The owner may work through an agent all day and open neither email nor the portal. The platform tells the agent instead, at the start of the next session.
The briefing at the start of the next session
What the agent calls. This is the exchange the agent has with Plexara on your behalf, shown for the technical reader. You ask in plain language; you never type any of it.
platform_info
-> failing_automations
name acme-pos-feed-rollup-611
run_id dpx_8539ce5b…
cause transient retryable true
consecutive_failures 1 new true
scheduled true
last_succeeded_at 2026-10-30T09:20:13Z
error no point-of-sale events arrived in the ten minutes
before 2026-10-30T09:30:00Z; the pos-sales feed has not published
agent_instructions This response carries a failing_automations list. It is
addressed to them, not to you. Relay it before you start
on their request, in your own words, and let them decide
what to do about it.The first call of every session lists the automations the person owns whose latest run failed: the run to open, its cause and whether a retry should help, the error’s last line, how many runs in a row have failed, and whether it is scheduled. The agent relays it before anything else. An automation stays on the list at every session start until a run of it succeeds or it is taken out of service, so the owner who works through an agent and reads neither email nor the portal still hears about it.
The end of the series
The demo tenant’s roll-up failed for nineteen minutes, sent one message when it started failing and one when it recovered, and its owner’s agent was told about it in between.
That closes the 600 series. A script the agent wrote in 602 now runs by hand, on a schedule, once per event, or once per request, under the authority of the person who saved it, and tells the right people once, in plain words, when it stops working and when it starts again.
Key terms
Four terms cover what happens when an automation fails.
Key Terms
- Incident
- A failing automation, from the failed run that opens it to the successful run that closes it. One failure message and one recovery message.
- Run failures
- The setting under Admin > Settings that names the channels every failing automation posts to, beside its owner’s email.
- Cause
- What a failed run says failed: the script, a service it called, memory, the platform, or a state conflict.
- Retryable
- Whether running the same version again unchanged is expected to succeed. It never makes the platform run it again on its own.