Summary

  • RunMyJobs has credible machinery for enterprise orchestration: an explicit job state model, event and dependency handling, locks, runtime limits, role controls, restart decisions, hybrid connectivity and current observability features. Those controls can reduce repetitive scheduling and monitoring work, especially in SAP-heavy estates. They do not by themselves make an external business operation atomic, idempotent or correct.
  • Recovery is the decisive product test. Redwood's documentation distinguishes uncertain, unknown, modified, overdue and operator-waiting states, and lets a team restart a whole workflow, a step or only failed processes using old or updated definitions. This is useful precision, but it also leaves consequential choices with people who must understand what committed in the target system before they press restart.
  • Public customer evidence supports real production use and some substantial improvements, but most outcome figures are vendor-selected and omit observation periods, error definitions and intervention counts. Public release records are more instructive about the operating surface: recent fixes cover unexpected executions, skipped schedules, lost connectivity and jobs stuck in intermediate states.
  • The commercial case should be measured as cost per accepted workflow, not price per job execution. Subscription, migration, connector maintenance, monitoring, exception labour, failed side effects, parallel running and exit work belong in the numerator; only workflows that deliver the correct business result by the required time without an unacceptable duplicate or permission error belong in the denominator.

The difficult job is the one that half worked

At 01:00, an enterprise scheduler starts a routine order-to-cash sequence. It extracts approved orders from an ERP system, sends a file to a warehouse service, updates a finance table, waits for an acknowledgement and releases the next step. The diagram is a tidy row of boxes. The failure is not.

Suppose the warehouse accepted the file but the acknowledgement never reached the scheduler. The local process reports a timeout. A simple retry might ship the order twice. Marking the task complete might conceal that the receiving service rejected half the records. Restarting the whole workflow could repeat the extract against data that changed at 01:07. Waiting for a person avoids an automatic duplicate, but it consumes the time before the morning dispatch deadline. The correct action depends on state held in several systems, not on the colour of one box.

That is the practical setting for evaluating RunMyJobs, Redwood Software's workload automation and service-orchestration platform. The software is meant to schedule and coordinate recurring work across SAP, Oracle, operating systems, databases, data platforms, cloud services and custom applications. Redwood describes a low-code editor, reusable templates and an automation catalog. Those are useful ways to define work. Yet the durable value of an orchestration product lies in the less photogenic details: how it represents a job that may still be running after contact is lost, how it prevents concurrency, how an operator sees a missed calendar window, which version of a changed definition is used on restart, and whether the customer can prove the business result rather than merely see a green completion status.

RunMyJobs has more substance here than a generic flow-diagram product. Its public documentation exposes a detailed state machine and several recovery controls. It also makes clear that the customer still owns important parts of correctness. A scheduler can preserve and reason about its own execution record. It cannot automatically reverse a payment, un-send a file or know whether a third-party API committed before its connection failed. The product can provide the control point. The workflow designer must provide the transaction boundary, idempotency key, reconciliation query or human decision that makes recovery safe.

The right question is therefore not whether RunMyJobs can run jobs. It plainly can, at large scale in named enterprise deployments. The question is whether its combination of state, permissions, observability, connectors and operating practice lowers the cost of each accepted workflow after ordinary exceptions and system changes. That is a more demanding test than a successful demonstration, and a more useful one.

A Dutch legal entity inside a larger, changing group

The commissioned company identity needs separating from the product brand. The Global Legal Entity Identifier record identifies Redwood Software Nederland B.V. as an active Dutch private limited company, registered under number 30141687, with a legal and headquarters address in Houten and a creation date in April 1997. Redwood's current contact page presents the same entity and address as its Netherlands office under “Redwood Software Europe.” Redwood as a business says it was founded in the Netherlands in 1993, so the group's founding date and this legal entity's creation date should not be treated as interchangeable.

The parent chain is less transparent in free official identity data. The LEI record reports parent-information exceptions rather than naming a direct or ultimate parent. At group level, the public history is clearer. Turn/River Capital made a €315 million investment in 2021. Vista Equity Partners and Warburg Pincus agreed to buy Redwood in 2024, and chief executive Kevin Greene wrote that the acquisition closed in December 2024. That establishes current financial sponsorship of the Redwood group, but it does not establish from public evidence which intermediate holding company directly owns the Dutch B.V. or which Redwood entity signs every regional customer contract.

The product boundary matters too. The group expanded through acquisition. It bought Tidal Software and then Cerberus in 2023, after an earlier combination with the business behind ActiveBatch and JSCAPE. Redwood now describes RunMyJobs, ActiveBatch and Tidal as three distinct workload-automation offerings. JSCAPE and Cerberus address managed file transfer. Redwood Finance Automation overlaps with finance processes, while RunMyJobs is the general orchestration platform that can also run finance work. A feature, customer result or connector belonging to one product should not be silently credited to another.

This distinction is not pedantry. Acquisitions can widen a catalog without creating one common control plane, support model or migration path. A buyer should ask which legal entity is the counterparty; which product and edition the quote covers; whether a connector is native to RunMyJobs or belongs to an adjacent portfolio product; where support responsibility sits; and what happens to licensing if the estate later adopts Tidal, ActiveBatch, a managed-file-transfer product or a dedicated finance module. “Redwood” is a corporate family. It is not a sufficient technical specification.

What RunMyJobs actually controls

In the SaaS design, RunMyJobs supplies a customer-specific central environment and the scheduler's system of record. Redwood's technical SaaS overview says the service runs on Amazon Web Services, while connections to systems inside the customer network pass through a Secure Gateway. Operating-system work generally uses a Platform Agent on the target server. ERP systems, databases and web services can be reached through the gateway with target-specific services and connectors.

This is a hybrid control architecture, not a magical absence of customer-side software. Redwood's current marketing often calls the platform agentless, and some integrations do not require an agent on each target. But the Platform Agent installation guide says an agent is installed at operating-system level when RunMyJobs needs to execute local server work. It requires an outbound HTTPS connection to the Redwood cloud, must remain synchronized through auto-update, and depends on firewall and proxy conditions that do not modify the encrypted traffic. A Secure Gateway is itself a designated agent or, in the newer 2026.1 architecture, part of an updated gateway design.

The distinction assigns labour. Redwood operates the central SaaS infrastructure, database and application releases. The customer still installs and monitors local components where required, maintains service accounts and OS permissions, keeps network paths available, tests its target-system connectors, and owns the applications that actually perform the work. Logs for work running on a Platform Agent may reside on the machine that executed it. The platform can reduce server administration for the central scheduler while leaving a meaningful integration and endpoint estate.

RunMyJobs represents work as jobs and workflows. A workflow contains sequential steps; calls inside a step can execute in parallel. Jobs can wait for events, locks, queues or other jobs. Events can be raised by file arrival, process completion, monitors or people, and repeated event raises form a queue. These primitives are well suited to nightly close, billing, data delivery and SAP background work because the dependencies are explicit and the execution history is centralized.

The scheduler is still only one participant. A job may invoke a stored procedure, an SAP transaction, a shell script, a REST endpoint or a managed service. RunMyJobs can record that the invocation started, returned an error or exceeded a limit. The receiving system decides whether its own operation is transactional. If an HTTP call creates an invoice and its response disappears, no scheduler can infer the business truth from a timeout alone. Reliable orchestration therefore depends on a contract between the workflow and every target: stable identifiers, queryable status, safe retries, bounded timeouts, explicit exit codes and compensating actions where rollback is impossible.

This is why connector count is an incomplete measure. A connector can remove boilerplate authentication and expose useful job types, yet production reliability also depends on API version compatibility, target permissions, pagination, rate limits, response semantics and the customer's configuration. A pre-built integration lowers initial effort. It does not eliminate version drift at either end.

The state machine is the real user interface

RunMyJobs' most informative public artifact is its job-status documentation. It lists initial states such as New and Scheduled; pending states such as EventWait, LockWait, Dispatched and Assigned; active states including Running, Waiting and Uncertain; final states including Completed, Error, Killed, Canceled and Unknown; and special states such as Modified, Never and Overdue.

These distinctions are operationally valuable. “Uncertain” means the runner ended early or the job server restarted while the job was running, and RunMyJobs is waiting to see whether an accurate termination message arrives. If it does not, the job becomes Unknown. “Modified” means a resubmit or restart failed and will not start without intervention. “Overdue” means a job missed the first available time window. “Never” can indicate conflicting time windows or the absence of a running server able to execute it. Each state narrows the investigation more effectively than a generic failure flag.

But a precise state is not a completed recovery. Unknown does not say whether an external side effect occurred. Overdue identifies a missed start, not whether starting late remains safe. Modified tells an operator that a restart could not be formed, not which parameter now represents the business intent. The scheduler's record is necessary evidence, not the whole truth.

The status-handler controls show both the platform's power and its risk. A workflow can continue, jump to another step, request a restart, restart automatically, restart after a delay, restart the whole chain or restart only failed processes. It can use the definitions captured when the workflow was submitted or the current master definitions. An operator responding to a restart request can abort, continue as if a status were complete, hold a restarted step for inspection or restart immediately.

Those are meaningful choices. Using the original definition preserves reproducibility. Using the latest definition lets a team fix a defect before retrying. Restarting only failed calls avoids repeating successful work. Holding the step creates time to change parameters. Yet none is universally correct. A “successful” sibling call in the same parallel step may have produced a side effect that must be reversed because another call failed. A corrected master definition may change more than the defect. Restarting from the beginning may repeat completed calls. Continuing as completed can turn a technical workaround into a silent business omission.

RunMyJobs also offers job locks to prevent simultaneous execution and counted or shared/exclusive variants to control concurrency. This is good preventive machinery, but it works only when the right jobs request the right lock. It does not stop a duplicate created by an external system after a lost acknowledgement, nor does it provide exactly-once delivery across unrelated databases and APIs. The reliable pattern is layered: use a scheduler lock to avoid known concurrency, an idempotency key or business key at the target, and a reconciliation step that checks the result before any retry.

Retry loops receive similarly useful but conditional treatment. Workflow steps can cap the number of starts, and process definitions can set restart delays and actions. Runtime limits can raise events or alerts when a task runs too long or too briefly. Those controls prevent some runaway behavior, provided designers set realistic limits and operators do not repeatedly reset them. A limit that is too low creates false failures at peak volume; one that is too high delays recovery. Historical runtime is informative only when volume and upstream behavior remain comparable.

The strongest reading is that RunMyJobs supplies a disciplined language for failure. That is valuable. The weaker, and unsupported, reading is that the language automatically chooses the correct business recovery. It does not, because no general scheduler can.

Nine ordinary failures and what the platform can really do

A missed trigger. A calendar error, paused queue, unavailable server or lost event can leave work Scheduled, EventWait, Never or Overdue. The monitor and SLA rules can make the condition visible. Recovery still needs a policy: run late, skip, backfill or wait for the next period. A payroll extract and an hourly cache refresh cannot share the same default.

Partial execution. A workflow step can contain several calls. Status handlers can restart only failed calls, while the rest are marked skipped in the restarted step. That saves work when calls are independent and successful completion is trustworthy. It is unsafe when the calls form a business transaction. The customer must define compensation or reconciliation outside the diagram.

A duplicate job or side effect. Locks and queue limits can prevent two scheduler jobs from running together. They cannot prove that a remote write happened once. The target application needs a unique request key, duplicate detection or a query that confirms the outcome. This is especially important for payments, orders, journal postings, user creation and file delivery.

A failed dependency. Events, wait states and sequential workflow steps express dependencies clearly. A failure handler can stop, branch, retry or ask an operator. The hard question is whether a downstream job should consume the last good input, wait indefinitely or publish a degraded result. That remains a business rule.

Credential expiry. RunMyJobs has credential objects, role-based privileges and support for external vault integration. That centralizes access better than secrets embedded in scripts. It does not mean every remote token rotates automatically or that a changed SAP, cloud or database credential reaches every path before expiry. Credential inventory, expiry alerts, test connections and emergency rotation remain deployment work.

Connector drift. Managed SaaS and an automation catalog can deliver updates without a traditional central-server project. The target systems still change. SAP support packages, API versions, database drivers, proxy policies and identity-provider settings can alter behavior. A connector release must be tested against representative jobs and failure paths, not only a login check.

A silent data error. This is the most important gap in any scheduler. A process can return code zero while loading yesterday's file, dropping records or applying the wrong exchange rate. RunMyJobs can preserve logs, parameters and execution history, but a green job status is not a business assertion. Accepted workflows need row-count checks, control totals, freshness rules, reconciliation against the target and a named owner for exceptions.

A retry loop. Maximum starts, delay settings, runtime limits and operator requests can bound automatic retries. They do not make retries harmless. A sound workflow records the reason for each attempt, backs off where appropriate, stops before an upstream rate limit or duplicate risk becomes worse, and escalates with enough context for a person to decide.

An escalation bottleneck. Operator Messages deliberately place some decisions with people. That is safer than blind continuation, but a queue of messages can become the system's limiting resource. The relevant measures are pages per thousand accepted workflows, time to qualified acknowledgement, hand-offs before resolution and decisions made without adequate target-system evidence. An attractive dashboard does not help if only one experienced administrator can interpret the exception at 03:00.

RunMyJobs has a documented control for most of these conditions. It has no public evidence that every customer configures those controls well, and no universal mechanism can remove the application-specific parts. Procurement should reward the product for making the states observable while charging the deployment for every remaining human and system dependency.

Observability helps only when completion means the right thing

Redwood added standard dashboards through Redwood Insights and expanded the offer in RunMyJobs 2026.1. Its 2026.1 product update describes Insights Premium with role-specific dashboard design and 15 months of historical data, plus integrations with SAP Cloud ALM, Splunk, Dynatrace, New Relic and AppDynamics. The same release describes multiple active Cloud Gateways, routing by network or domain and automated failover.

This is a sensible direction. An operator should be able to see rising runtimes, recurrent errors, gateway health, queue pressure and deadline risk without assembling every report by hand. A finance owner should see whether the close finished, not learn the scheduler's internal terminology. Long history helps distinguish a real regression from quarter-end volume.

The caveat is semantic. If a job says Completed whenever a script exits cleanly, Insights will faithfully aggregate that definition. If a skipped child is counted as completed in one dashboard measure, an analyst needs to know. Redwood's own Insights 1.4 release notes recorded a fix that added Skipped jobs to Completed job counts, an example of why metric definitions deserve inspection. Observability compresses telemetry; it does not improve the truth of the underlying signal.

Redwood RangerAI adds a separate capability layer. From RunMyJobs 2025.4, Redwood says its assistants can search product knowledge, suggest troubleshooting, generate scripts and document jobs. These may reduce lookup and first-draft work. They should not be confused with the deterministic scheduler or with a production outcome. No public task-level accuracy, unsafe-suggestion rate, customer acceptance rate or controlled comparison was found for these assistants. A generated script must still pass code review, permission review and non-production tests. A suggested fix must still be reconciled with the external system's state. The model can improve an operator's interface; the product controls the execution; the customer's systems determine the result.

Production evidence is real but uneven

Redwood can point to named enterprises and long-lived, consequential workloads. The evidence is strongest when a customer or public buyer describes its own use, and weaker when a vendor case study supplies an impressive percentage without a method.

A useful independent signal comes from the South Florida Water Management District. In a June 2025 governing-board packet, district staff described RunMyJobs as integrated with its on-premises SAP S/4HANA system for financial postings, data integrations and scheduled tasks. Staff said the implementation had improved reliability, reduced manual intervention and continued to operate without incident. The board material also attached a concrete five-year commercial request. This is credible evidence of paid production use, but it does not state the number of workflows, the observation start, the definition of an incident, the intervention rate or a baseline failure count.

Vendor customer stories add scale and task detail. Redwood says technology distributor ALSO reduced more than 46,000 SAP job definitions to 570 Redwood scripts while supporting more than 5,000 orders a day. Its utility summary says Stadtwerke München reduced a meter-to-cash sequence from 14 hours to eight and describes daily invoicing as fully accurate. An older Epson case study says 14,000 event-driven processes ran each day and attributes 42 days of annual SAP processing time saved to RunMyJobs.

These are material claims, but they answer different questions. Reducing definition count shows consolidation, not error-free execution. A shorter batch window may come from scheduling, parallelism, application changes, infrastructure or all four. An annualized saving depends on a baseline and observation period. “Accurate” needs a denominator, an error definition and a treatment of corrected exceptions. The case studies do not publish those methods, retry counts, support tickets or failed side effects. They should establish plausibility and reference-check candidates, not a forecast for another buyer.

The most valuable evidence may be Redwood's own record of defects and incidents because it names real failure mechanisms. The public RunMyJobs 2025.4 notes say version 2025.4.0.0 introduced a regression in which a job-server restart during a closed time window could cause unexpected job executions after an upgrade from 2025.3. Later point releases addressed SAP connectivity that could leave jobs in Dispatched, Assigned or New until a manual process-server restart, and an issue with OS jobs stuck in Dispatched while file events were not reported. The base release fixed a first-Monday schedule that could skip its first occurrence, a rare gateway failure after a network interruption, a BusinessObjects job left Running after the remote report had ended, and a workflow waiting indefinitely because a remote failure state was not checked.

Those disclosures do not prove the platform is unusually defective. Mature enterprise software has defects, and transparent release notes are a positive operating signal. They do prove that the commissioned failure modes are not theoretical. Missed runs, unexpected runs, lost connectivity and misleading intermediate states have existed in supported code. They also undercut absolute marketing phrases such as “zero upgrade risk.” The responsible claim is narrower: SaaS can transfer much upgrade execution to Redwood, while customers still need representative pre-production validation, change communication and a recovery plan.

The April 2024 Dublin events make the same point at service level. Redwood's 20 April incident record described unhealthy production-cluster nodes, intermittent access, agents briefly disconnecting and an emergency migration to a stabilized cluster. A 23 April record described further network instability and monitoring that sometimes showed environments down while processes continued. The distinction between control-plane visibility and job execution matters. A customer needs to know which workflows continue locally or remotely, which new work can start, how status catches up, and what operators do when the dashboard itself is uncertain.

Price per execution is not cost per accepted workflow

Redwood does not publish a standard tariff. Its pricing page asks for a quote and says predictive SLA management, standard Insights, enterprise connectors, up to three pre-production environments, support and SaaS operation are included in the starting platform. Third-party pricing material says usage is based on completed process executions in production and non-production, but the binding definition will be in the contract.

Public procurement records reveal useful ranges without producing a universal rate. A 2026 Texas invitation for bid specified 750,000 annual usage capacity, unlimited users and process servers, up to three non-production environments, an Oracle connector pack, Insights, a technical account manager, $40,000 for greenfield implementation and an overage rate of $0.02 rather than a stated standard of $0.03. It did not disclose the winning subscription price in the specification.

Illinois disclosed a $607,864.86 contract running from September 2024 to September 2027 for RunMyJobs SaaS Enterprise Edition, five million job executions, business-process automation and migration services for three environments. That averages about $202,622 a year, but dividing it by five million to manufacture a unit price would be misleading: the record does not say whether five million is annual or total capacity, and the amount bundles migration and additional capability. South Florida's 2025 board request was $291,834 for five more years, or about $58,367 a year, for its existing deployment. Its scope and volume differ.

The records show why a buyer needs its own workload model. The subscription can be significant, but labour and failure often dominate. A useful annual numerator includes:

The binding subscription. Include base platform, committed executions, overage, premium Insights, support tier, environments and any separate connector, transfer or finance products. Clarify whether retries, test runs, maintenance jobs, skipped jobs and child calls consume capacity.

Migration and parallel operation. Redwood's migration guide describes assessment, training, development and test deployment, hypercare and parallel running with the legacy product. It also says standard objects from Control-M, Automic, AutoSys and IBM Workload Scheduler can be migrated with tooling while custom developments need manual work. Count both vendors, both operating teams and reconciliation during the overlap.

Integration and lifecycle work. Count gateway and agent installation, service accounts, firewall changes, vault integration, connector tests, source-control and promotion practices, target upgrades and regression work. SaaS removes central infrastructure tasks; it does not remove the endpoints.

Operations and exceptions. Count monitoring, on-call coverage, alerts, operator decisions, application-team escalations, reprocessing, control-total investigation and business-owner sign-off. Include the cost of a wrong recovery, not only the ticket that recorded it.

Concentration and exit. Centralizing thousands of workflows can remove duplicate tools and knowledge, but it also increases the importance of one platform, one definition format and one operating skill set. Count exports, documentation, archived execution evidence, replacement connectors and the work to move or retire workflows at the end.

The denominator should be the number of accepted workflows: correct business outcomes delivered within the promised window, with complete audit evidence and no unacceptable duplicate, omission or permission breach. A workflow that uses 30 billable job executions is one outcome. A failed attempt followed by a successful retry may increase charged usage without increasing accepted outcomes. A green workflow later rejected by finance is not accepted. This unit connects the contract to what the enterprise actually wanted.

The economic case is strongest where RunMyJobs replaces several schedulers, reduces recurring manual starts, shortens a binding batch window and gives operators enough context to resolve exceptions faster. It is weaker where the estate has few cross-system dependencies, stable native scheduling, low support cost or highly bespoke integrations that the customer must keep rebuilding. The platform should beat the real baseline, not a hypothetical world in which every current task is performed by hand.

Automation removes shifts and creates stewardship

A successful workload-automation deployment changes labour rather than simply deleting it. Operators may stop launching 60 daily jobs or checking several consoles. Developers may reuse connectors and templates instead of writing scheduling wrappers. Business users may start approved workflows through self-service. Those are genuine transfers away from repetitive work.

Other work moves upstream. Someone must define calendars, time zones, dependencies, locks, credentials, thresholds, owners, recovery paths and data-quality assertions. Someone must decide whether a retry is safe after a partial commit. Someone must review release changes and connector compatibility. Someone must keep documentation aligned with the current workflow and ensure a departing expert does not remain the only person able to clear an operator message.

The supervision burden should be measured, not hidden inside “business as usual.” Track interventions per thousand accepted workflows, minutes of qualified investigation, application-team hand-offs, after-hours pages, manual reconciliations and exceptions that require the original workflow author. Separate launch work from steady-state work. A three-month cleanup that replaces years of scripts may be an excellent investment. A permanent dependence on expensive specialists for ordinary retries is not.

Permissions deserve the same attention. RunMyJobs supports built-in and custom roles and object-level controls. A centralized orchestrator can improve segregation of duties and auditability over shared service-account scripts. It can also become a powerful route into many systems. Test who can view and use credentials, alter definitions, run jobs immediately, approve changes, read logs and promote objects. Check the effective permissions in SAP, databases and cloud services as well as the scheduler. A least-privilege diagram is not proof until the accounts are exercised.

The alternatives are more varied than a vendor shortlist

The first alternative is the incumbent. A stable Control-M, Automic, AutoSys, IBM Workload Scheduler or native SAP estate may be unattractive but economically rational. Migration needs to produce enough reduction in support, infrastructure, batch time or operational risk to repay conversion and dual running. New user experience alone is rarely enough for a mission-critical scheduler.

The direct commercial alternatives are credible. BMC Control-M SaaS coordinates scheduled and conditional workflows from a central service. Broadcom Automic Automation spans mainframe, distributed, ERP and cloud work with SaaS and self-managed options. Stonebranch Universal Automation Center offers event-driven hybrid orchestration. They should be tested on the same recovery cases, not compared through connector counts and analyst positions alone.

Redwood's own ActiveBatch and Tidal may fit customers with different installed bases or integration preferences. Their common ownership does not make them identical to RunMyJobs, and a portfolio conversation should not replace a product-specific migration and operating test.

For a data team, Apache Airflow, Dagster, Prefect or a cloud-managed data orchestrator can be a realistic lower-licence-cost option. These systems suit workflows-as-code and data-platform ownership, but the customer carries more engineering and operations, and deep ERP control may require custom integration. For a small number of simple tasks, cloud schedulers, native ERP jobs, database scheduling and carefully operated scripts may be cheaper still. Their weakness appears when dependencies cross systems, exception handling fragments and audit evidence has to be assembled by hand.

Manual operation is also a baseline, but only for tasks where volume, timing and error consequence permit it. A two-minute daily check with a clear owner may be better than an elaborate integration. Conversely, a 14-hour meter-to-cash chain with dozens of sources is exactly where central state and recovery controls can earn their cost.

A proof should begin with failure, not the happy path

A serious evaluation needs representative work and permission to fail safely. Select 30 to 50 workflows across SAP, finance, data, files, cloud APIs and local operating systems. Include high-volume ordinary work, month-end peaks, tight deadlines and tasks with irreversible side effects. Record the incumbent's completion, operator effort, support tickets and cost for at least one normal cycle and one peak cycle.

Build the RunMyJobs version in development and test before production. For each workflow, define acceptance independently of the scheduler: target row counts, control totals, expected files, SAP document state, unique business keys, freshness and deadline. Mark which steps are idempotent, which have a compensation and which require a person. Do not accept “Completed” as the only assertion.

Then exercise the nine ordinary failures in a controlled environment. Delay an upstream event. Revoke a test credential. Interrupt a network connection after a request reaches a mock or non-production target. Send the same event twice. Leave one call in a parallel step failed after another succeeds. Change a connector or target API version. Restart a test job server during a closed time window. Create a long-running task and a task that returns success with an incorrect control total. Use synthetic records and reversible accounts; never inject faults into a live financial or customer process merely to make the trial dramatic.

Score each attempt in four layers.

Capability: Could the scheduler express the calendar, event, lock, permission, dependency, timeout and restart policy without unsafe custom code?

Product reliability: Did the integrated product detect the condition, preserve intelligible state, alert the right role, avoid an automatic duplicate, retain logs and perform the selected recovery on the tested version?

Production outcome: Did the receiving systems end with the correct business state by the deadline? How many attempts and human decisions were needed? Did audit evidence explain every side effect?

Economics: What was the fully loaded cost per accepted workflow, including consumed executions, engineering, monitoring, exception time and the expected cost of failures?

Record first-attempt acceptance, final acceptance, missed and duplicate side effects, median and tail recovery time, operator touches, after-hours alerts, support involvement and change-failure rate. Averages hide the one month-end workflow that occupies three teams for six hours. Report the 95th percentile and the worst consequential case.

Run the same task set against the incumbent and at least one simpler alternative. Where a direct competitor is shortlisted, use identical acceptance rules. Where native scheduling or a script is credible, include it. Human selection should be fixed before results are known, retries should be counted, and a manual correction should remain visible rather than being folded into a successful run.

Evaluate RangerAI separately. Give it bounded documentation, troubleshooting and script-drafting tasks on a named product version. Score whether the suggested answer cites the right product behavior, whether generated code compiles, whether a reviewer accepts it unchanged, and whether it passes safe tests. Do not add its score to scheduler reliability. A good assistant answer cannot rescue a duplicate payment, and a deterministic job can succeed without an assistant.

Finally, keep the trial running through a version or connector change. The core commercial question is not whether the platform works on the day Redwood's engineers help configure it. It is whether the customer's ordinary team can maintain state, permissions, observability and recovery when the surrounding systems move.

The judgment: strong controls, conditional economics

RunMyJobs is a credible enterprise orchestration product, particularly for organizations with substantial SAP workloads and cross-system dependencies. Its public documentation shows mature concepts: explicit execution states, event queues, locks, old-versus-new-definition restarts, bounded retries, operator messages, role controls, predictive SLA monitoring and hybrid connectivity. Current Insights and gateway work addresses a real need for better context in distributed operations.

The evidence does not support an unconditional claim of autonomous, error-free operation or lowest total cost. Customer outcomes are mostly selected by Redwood and rarely expose failure denominators or supervision. Public incidents and release notes show that the control plane, connectors and scheduling logic can themselves introduce the same classes of failure they are meant to manage. SaaS transfers infrastructure and upgrade execution, but mandatory change, customer-side connectivity, target semantics and recovery judgment remain.

A good buying case will have a narrow numerical shape: fewer manual starts, fewer consoles, lower tail recovery time, fewer duplicate or missed outcomes, a shorter binding batch window, and a lower cost per accepted workflow after subscription and migration. A weak case will count job executions, connector logos and green boxes while leaving reconciliation and escalation labour unmeasured.

The facts that would change this judgment are straightforward. Independent, task-level production results with observation periods and exception counts would strengthen it. Public reliability history against the 99.95% commitment, including scope and service credits, would clarify cloud risk. Contract language defining billable retries and non-production executions would improve unit economics. Evidence that connector and version changes preserve workflow semantics across representative estates would reduce lifecycle concern. Customer measurements showing sustained reductions in operator touches and support cases would confirm that labour disappeared rather than moved.

Until then, RunMyJobs should be valued for the quality of the recovery system a customer can build with it. The workflow diagram is the invitation. The state after a timeout, the evidence before a restart and the cost of reaching a correct result are the product.