Automation & Keepers
Automation & Keepers evaluated across whether the job survives the vendor, what can fire the call and who can check the condition was true, whether a run that never happened is visible, and the lateness the vendor will put in writing.
19providers tracked
7ranked (methodology v2026.11.1)
12 November 2026Ranking snapshot
28 September 2026oldest read · due 12 NovIndependent. Evidence-based.We rank with a published method and sourced evidence. No one can pay to rank.How it works
Set your country and amount to see your costs ·
Your setup
What your country changes
Pick a country to see which automation networks serve it. Nothing is hidden — any that does not is listed with that reason.- 🇺🇸 United States
- 🇨🇦 Canada
- 🇲🇽 Mexico
- 🇬🇧 United Kingdom
- 🇩🇪 Germany
- 🇫🇷 France
- 🇮🇹 Italy
- 🇪🇸 Spain
- 🇳🇱 Netherlands
- 🇨🇭 Switzerland
- 🇸🇪 Sweden
- 🇳🇴 Norway
This affects provider availability.
Requirements (0)
Preferences (0)
Preferences re-weight Fit for you, which needs your country.
More filters
Funding & access
7 providers match your requirements
Out of 7 ranked providers. 0 excluded.
What this ranks
Ranked here: automation and keeper services that notice when a contract call comes due and then make that call happen, for operators running routine business logic on a deadline.Not ranked here: services that only submit a transaction you have already decided to send, and security monitoring built to catch an attacker rather than run routine business logic.7 of the 19 assessed are ranked; 12 were turned away by name. Who, and whyRequirements narrow the list; they never change a published ChainChoice Score. How the ranking works
TukTuk (Helium)
How TukTuk (Helium) was chosen
Wins the weighted total without leading any single criterionAn open-source Solana crank protocol
80 / 100 out of 100published score, #1 of all 7 worldwide
Evidence
High
4/4 criteria scored, with 4 dated sources quoted.What can fire the call, against what target, and who can check the condition was trueWhether the job survives the vendor: who else can turn the crank, and what end-of-life is published
Why it leads
- TukTuk (Helium) is 11 points ahead of KeeperHub, mainly because it scores higher on its visibility of the non event and its survives the vendor.
- Ahead of KeeperHub on visibility of the non event (+4.5 points) and survives the vendor (+3.7 points)
- Provider states broad availability
Tradeoff
Published lateness bound: 3 points below the best in this ranking
Share
#ProviderPriceCompare
2
Hosted visual workflow runner
69 / 100 out of 100
3
An EVM chain
68 / 100 out of 100
4
Closed-catalogue DeFi position automation
66 / 100 out of 100
5
A permissionless onchain keeper marketplace
65 / 100 out of 100
6
MI
Write the condition as a TypeScript function
63 / 100 out of 100
7
The reference keeper network
≤41 / 100 out of 100
Chainlink Automation (migrating to Chainlink Runtime Environment) has shut down (The reference keeper network, now past its own sunset: the Ethereum Mainnet v2.1 registry emitted its last UpkeepPerformed on 2026-08-05 and has emitted only cancellations, withdrawals and one payee update since, while on 2026-09-28 it still reported paused=false with 192 upkeeps and 18,830.53 LINK parked in it; the designated successor CRE is demonstrably executing onchain minute-by-minute but is gated behind a manually reviewed approval.).
Compare providers (0)
See key differences in features, fees, security and more.
Trigger surface and predicate locus
What can fire the call, against what target, and who can check the condition was true
28% of the published criteria weight. Scored 0–10 from the published evidence; the order below is by this criterion, then the published ranking.
| Provider | Trigger surface and predicate locus (0–10) | ChainChoice Score |
|---|---|---|
| TukTuk (Helium) | 8 | 80 |
| Reactive Network | 8 | 68 |
| KeeperHub | 6 | 69 |
| Mimic Protocol | 6 | 63 |
| Chainlink Automation (migrating to Chainlink Runtime Environment) | 6 | 41 |
| DeFi Saver Automation | 4 | 66 |
| Keep3r Network | 2 | 65 |
Survives the vendor
Whether the job survives the vendor: who else can turn the crank, and what end-of-life is published
30% of the published criteria weight. Scored 0–10 from the published evidence; the order below is by this criterion, then the published ranking.
| Provider | Survives the vendor (0–10) | ChainChoice Score |
|---|---|---|
| Keep3r Network | 9 | 65 |
| TukTuk (Helium) | 8 | 80 |
| KeeperHub | 6 | 69 |
| DeFi Saver Automation | 4 | 66 |
| Mimic Protocol | 3 | 63 |
| Reactive Network | 2 | 68 |
| Chainlink Automation (migrating to Chainlink Runtime Environment) | 2 | 41 |
Visibility of the non event
Whether a run that never happened is visible, or the job just goes quiet
24% of the published criteria weight. Scored 0–10 from the published evidence; the order below is by this criterion, then the published ranking.
| Provider | Visibility of the non event (0–10) | ChainChoice Score |
|---|---|---|
| TukTuk (Helium) | 7 | 80 |
| Reactive Network | 7 | 68 |
| Chainlink Automation (migrating to Chainlink Runtime Environment) | 7 | 41 |
| DeFi Saver Automation | 5 | 66 |
| KeeperHub | 4 | 69 |
| Keep3r Network | 4 | 65 |
| Mimic Protocol | 4 | 63 |
Published lateness bound
The lateness the vendor will put in writing, and the conditions under which it declines to execute
18% of the published criteria weight. Scored 0–10 from the published evidence; the order below is by this criterion, then the published ranking.
| Provider | Published lateness bound (0–10) | ChainChoice Score |
|---|---|---|
| DeFi Saver Automation | 9 | 66 |
| Chainlink Automation (migrating to Chainlink Runtime Environment) | 8 | 41 |
| KeeperHub | 7 | 69 |
| TukTuk (Helium) | 6 | 80 |
| Mimic Protocol | 6 | 63 |
| Reactive Network | 5 | 68 |
| Keep3r Network | 4 | 65 |
All 4 published criteria
Every ranked row’s score on each criterion, in the published order. Choose a column to order by it.
| Provider | ChainChoice Score | |||||
|---|---|---|---|---|---|---|
| 1 | TukTuk (Helium) | 8 | 8 | 7 | 6 | 80 |
| 2 | KeeperHub | 6 | 6 | 4 | 7 | 69 |
| 3 | Reactive Network | 8 | 2 | 7 | 5 | 68 |
| 4 | DeFi Saver Automation | 4 | 4 | 5 | 9 | 66 |
| 5 | Keep3r Network | 2 | 9 | 4 | 4 | 65 |
| 6 | Mimic Protocol | 6 | 3 | 4 | 6 | 63 |
| 7 | Chainlink Automation (migrating to Chainlink Runtime Environment) | 6 | 2 | 7 | 8 | 41 |
How this ranking works
How firm the #1 is, the per-criterion arithmetic behind each score, who pays ChainChoice, and which automation & keepers were assessed and left out.
FirmThis verdict holds under every one-point re-read
See the arithmetic
Every published criterion was moved up and down by one point and the ranking re-run. The same product came first each time. The published rankings file
Why this score4 published criteria · leads 2 of 4
Published criterionWtScore, and the best hereGap/10 out of 10Pts
What can fire the call, against what target, and who can check the condition was true6.7·87.2
Whether the job survives the vendor: who else can turn the crank, and what end-of-life is published7.2−187.7
Whether a run that never happened is visible, or the job just goes quiet5.8·75.4
The lateness the vendor will put in writing, and the conditions under which it declines to execute4.3−363.5
Σ methodology points23.7/32
Each bar is the score on that criterion’s own 0–10 scale, never rescaled to the pool. The dark line is the best any product here reached on that axis. Wt is the most the criterion can add to the 86-point weighted total. Pts is weight × score × 32; the sum is the methodology score, and each weighted point behind the leader costs 2.6 on the displayed score. how these are weighted
Why it ranks first
Why TukTuk (Helium) leads this category right now
An open-source Solana crank protocol: the buyer posts a task with a per-crank SOL reward and any anonymous signer may execute it, so firing is time-only, but the executor set, the due-condition and the failed run are all public chain state — and a task can return its own successor, keeping a conditional loop entirely onchain. Strongest on what can fire the call, against what target, and who can check the condition was true (8/10): Firing is time-only: the TriggerV0 enum holds Now and Timestamp(i64), and a separate cron program queues tasks on a schedule. A task can call any instruction on any program, and RunTaskV0 checks the due-condition onchain ("task.trigger.is_active()"), so anyone can replay it. Weakest on the lateness the vendor will put in writing, and the conditions under which it declines to execute (6/10): No SLA, uptime figure or check cadence is published; the homepage promises tasks "run on time, every time". The docs state the decline conditions: the reward must exceed the crank cost or "crankers will not be incentivized to run your task", and a cron that runs out of funding leaves the queue. Published price: No rate card, subscription or vendor invoice exists; the only price mechanics are on https://www.tuktuk.fun/docs/overview, fetched 2026-09-28 and unchanged since August: "Creators of Task Queues set their payment per-crank turn in SOL.
Best for
What can fire the call, against what target, and who can check the condition was true — 8/10
Main tradeoff
Read this before committing: the programs are UPGRADEABLE and one authority controls both. tuktukUrfhXT6ZT77QTU8RQtvgL967uRuVagWF57zVA and cronAjRZnJn3MTP3B9kE62NWDrjSuAPVXf9c4hu4grM are owned by BPFLoaderUpgradeab1e11111111111111111111111, and their programData accounts both report the SAME upgrade authority, pULUgsYtKvT7qhsL8QJ2oJXYQUeCCdjtfawPnBqEr3U (read via getAccountInfo on mainnet-beta on 2026-08-14, and again at slot 451387271 on 2026-09-28). That account is system-owned with zero data; it held 2,426.04 SOL on 2026-08-14 and 200.00 SOL on 2026-09-28; whether it is a single keypair or a multisig vault cannot be determined from the account, and the vendor publishes nothing about who holds it. Everything this product scores well on — the unconstrained `crank_turner: Signer` that lets anyone execute your task — is code one key can replace (and that key did redeploy the tuktuk program at slot 448828254, matching release 0.2.11 on 2026-09-20), and there is no published continuity statement, sunset policy or security contact anywhere on the site or in its repository (no SECURITY.md, no CHANGELOG.md, /terms and /status both HTTP 404, status.tuktuk.fun NXDOMAIN). Three further things. (1) Firing is time-only: the published TriggerV0 enum is exactly {Now, Timestamp(i64)}, with cron expressions layered on by a second onchain program. There is no event, state, HTTP or cross-chain trigger. A conditional loop is supported without a server you own — a task's program can return its successor via RunTaskReturnV0, and the vendor publishes an instruction named `recurring_task` at https://www.tuktuk.fun/docs/api/cpi-example-sdk — but you must write and deploy that Solana program yourself; the platform evaluates nothing but the clock. (2) The executor count needs its caveat carried with it: seven distinct addresses ran RunTaskV0 in the August window, but four of them had their FIRST-EVER transaction funded from one wallet, 4SP9UEdkdPsFgEVmERLXZ4aUAFGCJ2JUuBgFyYAnv8AF, on 2026-08-11 — three in a single transaction. The chain supports 'at least two independent operator groups', not 'seven independent operators'. The set has since turned over: those four keys last ran on 2026-09-03, and a new address, BcS9rqkjquBDyi1faYqWYaLfW2Pc9fAXuBxoDHKYdYRM, first funded on 2026-09-02, paid for 47 of 50 runs sampled on 2026-09-28. No transfer read links its funder to 4SP9 or to the Helium-vanity keys, so its independence is unproven; the chain still shows at least two operator groups in the 30 days to 2026-09-28, but fewer are running today. (3) Nothing pushes: across all 23 published pages there is no webhook, alert, notification or email of any kind, so a defunded cron stops forever until a human polls — and the field the vendor's own monitoring page tells you to poll, removed_from_queue, is marked '// Deprecated: You should use the next_schedule_task instead' in the program source, while next_schedule_task appears on no page of the site. Separately, the homepage states the contracts are 'currently being audited. Use at your own risk.' with no auditor, report or date. PRICING, recorded as disclosure and ranked in no criterion: there is no subscription, no per-execution rate card and no vendor invoice. The buyer sets crank_reward per task in lamports (the CLI example at https://www.tuktuk.fun/docs/learn/create_a_task_queue uses --crank-reward 1000000, i.e. 0.001 SOL) and whichever anonymous signer executes it collects it; a live successful run logged 'Program log: Paying out reward 15000' (15,000 lamports) in signature 3iRR1cX8S7gbe3KiLDkG3KMhFu4V5D156YsaRPvibA9nnqhc7D6afoHxJpTraQsouKmhT3ewppsxfTR5fKXZSoLQ, slot 439184245, read on mainnet-beta 2026-08-14. That the crank reward is the ONLY fee is now verified rather than assumed: across all 17 .rs files of the tuktuk program, `uncollected_protocol_fees` appears exactly three times — twice as a struct field declaration in state.rs and once initialised to 0 in initialize_task_queue_v0.rs — with no code path anywhere that increments it. Pricing-shaped URLs tried, all HTTP 404 on 2026-08-14: /pricing, /docs/pricing, /terms.
Verify before signup
No rate card, subscription or vendor invoice exists; the only price mechanics are on https://
Recommendation summary
What should decide this category
If this vendor shut down tomorrow, could anyone else call your job — or does it simply stop?
Does your condition live in code a third party can replay, or inside the vendor’s own servers?
How would you find out that a scheduled run silently stopped happening?
Quick picks
Strong options in this category
Start with the lead choice first, then use the shortlist only if you still need a challenger or stronger fit for a specific setup.
Best overall
TukTuk (Helium)
An open-source Solana crank protocol: the buyer posts a task with a per-crank SOL reward and any anonymous signer may execute it, so firing is time-only, but the executor set, the due-condition and the failed run are all public chain state — and a task can return its own successor, keeping a conditional loop entirely onchain.
An open-source Solana crank protocol: the buyer posts a task with a per-crank SOL reward and any anonymous signer may execute it, so firing is time-only, but the executor set, the due-condition and the failed run are all public chain state — and a task can return its own successor, keeping a conditional loop entirely onchain. Strongest on what can fire the call, against what target, and who can check the condition was true (8/10): Firing is time-only: the TriggerV0 enum holds Now and Timestamp(i64), and a separate cron program queues tasks on a schedule. A task can call any instruction on any program, and RunTaskV0 checks the due-condition onchain ("task.trigger.is_active()"), so anyone can replay it. Weakest on the lateness the vendor will put in writing, and the conditions under which it declines to execute (6/10): No SLA, uptime figure or check cadence is published; the homepage promises tasks "run on time, every time". The docs state the decline conditions: the reward must exceed the crank cost or "crankers will not be incentivized to run your task", and a cron that runs out of funding leaves the queue. Published price: No rate card, subscription or vendor invoice exists; the only price mechanics are on https://www.tuktuk.fun/docs/overview, fetched 2026-09-28 and unchanged since August: "Creators of Task Queues set their payment per-crank turn in SOL.
Best for: What can fire the call, against what target, and who can check the condition was true — 8/10
What can fire the call, against what target, and who can check the condition was true · weight 28%8/10Whether the job survives the vendor: who else can turn the crank, and what end-of-life is published · weight 30%8/10Whether a run that never happened is visible, or the job just goes quiet · weight 24%7/10The lateness the vendor will put in writing, and the conditions under which it declines to execute · weight 18%6/10
Quick pick
KeeperHub
Hosted visual workflow runner for onchain automation: five documented trigger types (schedule/cron, per-block, contract event, webhook, manual) firing arbitrary contract calls from a Turnkey wallet, with the condition evaluated entirely inside vendor infrastructure — offset by an Apache-2.0 self-hostable scheduler and executor whose production Kubernetes values are published, and a numeric SLA that only begins at the $299 tier.
Hosted visual workflow runner for onchain automation: five documented trigger types (schedule/cron, per-block, contract event, webhook, manual) firing arbitrary contract calls from a Turnkey wallet, with the condition evaluated entirely inside vendor infrastructure — offset by an Apache-2.0 self-hostable scheduler and executor whose production Kubernetes values are published, and a numeric SLA that only begins at the $299 tier. Strongest on the lateness the vendor will put in writing, and the conditions under which it declines to execute (7/10): The pricing table lists an SLA of 99.9% on the Business tier and 99.999% on Enterprise, and none on the two cheaper tiers. KeeperHub's own status page shows 99.3% 90-day uptime for its scheduler. Sponsored gas stops at the cap and falls back to the wallet, and the run fails if that wallet holds no native balance. Weakest on whether a run that never happened is visible, or the job just goes quiet (4/10): Run logs and error codes, including codes for a trigger that could not start, exist only in the vendor dashboard, kept 7, 30 or 90 days by tier. Alerts are nodes inside a workflow, so none fires for a run that never started, and the FAQ tells buyers to "consider redundant monitoring through other channels". Published price: Fetched 2026-09-28 from https://keeperhub.com/pricing; every figure is unchanged since 2026-08-14. Pay per execution: "$0.01", "Free to start. No commitments.", Executions "5,000", Gas credits "$1".
Best for: The lateness the vendor will put in writing, and the conditions under which it declines to execute — 7/10
What can fire the call, against what target, and who can check the condition was true · weight 28%6/10Whether the job survives the vendor: who else can turn the crank, and what end-of-life is published · weight 30%6/10Whether a run that never happened is visible, or the job just goes quiet · weight 24%4/10The lateness the vendor will put in writing, and the conditions under which it declines to execute · weight 18%7/10
Quick pick
Reactive Network
An EVM chain whose contracts subscribe to origin-chain event logs and to validator-emitted CRON events, then fire arbitrary calldata at any of 12 mainnets through a callback proxy — the predicate is Solidity anyone can replay, but one single EOA delivers every callback on every chain.
An EVM chain whose contracts subscribe to origin-chain event logs and to validator-emitted CRON events, then fire arbitrary calldata at any of 12 mainnets through a callback proxy — the predicate is Solidity anyone can replay, but one single EOA delivers every callback on every chain. Strongest on what can fire the call, against what target, and who can check the condition was true (8/10): Four documented trigger types: event logs, cross-chain origins, per-block, and CRON intervals up to every 10,000 blocks. The predicate is the buyer's own Solidity on Reactive Mainnet, which anyone can replay. Subscriptions match exact values only, and the first 160 bits of each callback payload are overwritten. Weakest on whether the job survives the vendor: who else can turn the crank, and what end-of-life is published (2/10): One address, 0x777f67156e2bb3ee9cea6866c2656b099b67d132, sent every callback to the Ethereum and Arbitrum proxies in the 30 days to 2026-09-28 and every sampled cron() call. "Only authorized validator root addresses can call cron()". No node client or cranker is published, and no end-of-life statement exists. Published price: No pricing page exists. On 2026-09-28 https://reactive.network/pricing and https://dev.reactive.network/pricing both returned HTTP 404.
Best for: What can fire the call, against what target, and who can check the condition was true — 8/10
What can fire the call, against what target, and who can check the condition was true · weight 28%8/10Whether the job survives the vendor: who else can turn the crank, and what end-of-life is published · weight 30%2/10Whether a run that never happened is visible, or the job just goes quiet · weight 24%7/10The lateness the vendor will put in writing, and the conditions under which it declines to execute · weight 18%5/10
Quick pick
DeFi Saver Automation
Closed-catalogue DeFi position automation: pre-deployed, individually auditable onchain Trigger contracts fire pre-registered Action recipes against a user's own Safe or DSProxy, executed exclusively by an onchain-allowlisted DeFi Saver bot fleet. 48 individual trigger pages are documented; 47 Trigger-named contracts carry deployed Ethereum mainnet addresses.
Closed-catalogue DeFi position automation: pre-deployed, individually auditable onchain Trigger contracts fire pre-registered Action recipes against a user's own Safe or DSProxy, executed exclusively by an onchain-allowlisted DeFi Saver bot fleet. 48 individual trigger pages are documented; 47 Trigger-named contracts carry deployed Ethereum mainnet addresses. Strongest on the lateness the vendor will put in writing, and the conditions under which it declines to execute (9/10): "The system checks all automated positions every minute" appears on a public help page. Network congestion is listed as a risk. A strategy stops executing once debt falls to $5,000 or below on Ethereum, and a GasPriceTrigger contract enforces an onchain gas ceiling. No SLA or landing commitment is published. Weakest on what can fire the call, against what target, and who can check the condition was true (4/10): The catalogue is fixed: "Triggers like actions can only be added by the admin through the DFSRegistry contract", and only the DFS team creates strategies. Each trigger is a published onchain contract, and the executor "checks if every trigger in strategy is triggered" before it runs. 48 trigger pages are documented. Published price: Fetched 2026-09-28 from https://help.defisaver.com/automations/fees (and its .md source), unchanged since August: "Automations have a fee of 0.05% on each triggered automation transaction." | "Note that simply enabling and keeping any automated strategy…
Best for: The lateness the vendor will put in writing, and the conditions under which it declines to execute — 9/10
What can fire the call, against what target, and who can check the condition was true · weight 28%4/10Whether the job survives the vendor: who else can turn the crank, and what end-of-life is published · weight 30%4/10Whether a run that never happened is visible, or the job just goes quiet · weight 24%5/10The lateness the vendor will put in writing, and the conditions under which it declines to execute · weight 18%9/10
Considered and not ranked
12 products we looked at and left out
A shortlist is only honest if it says who it turned away. Each of these was assessed against the same published criteria as the ranked table and excluded for a stated reason — not overlooked.
We assessed 19 products here and rank 7 — 37% of what we looked at. That share is of the products we assessed, not of the category: how many exist is not something we can count, so we do not claim a number for it.
Tenderly Web3 ActionsGelato Web3 Functions / Gelato Automate· Ranked elsewhereOpenZeppelin Defender (Actions / Autotasks)· No longer operatingPyth Express Relay· No longer operatingDitto Network· Evidence incompletePowerPool / Power Agent v2· No longer operatingBrahma (Console / Automation Accounts)· No longer operatingClockwork (Solana)· No longer operatingAutonomy NetworkOlas / AutonolasOtimHalliday
What this ranking does not assess
Every failure family that applies to this category is scored by one of its criteria.
Which criterion scores each family, and why the others do not apply, is in /data/risk-coverage.json.
How this ranking is built
Reviewed on what can fire the call and who can replay the condition, whether the job survives the vendor, whether a run that never happened is visible, and the lateness the vendor will put in writing. Weights are the engine’s: 30 / 28 / 24 / 18. There is deliberately no cost axis — per-execution price is already scored on the sibling page that ranks bundlers and paymasters, so it appears here only as recorded disclosure.
Data checked Sep 2026 · Independent rankings · We show our work
How this page is reviewed
Reviewed means every product ranked on this page was read against its sources on or after that date; every ranked category is re-read at least every 45 days. Models research, extract and parse. A deterministic engine ranks. Every quote passes an adversarial refute pass.
Accountable for this review: Mathias Siemonsmeier, Founder.
How we review · Review calendar · Corrections log · How we make money
Direct answer
What is the best automation network in 2026?
TukTuk (Helium) ranks #1 overall for automation & keepers on ChainChoice. An open-source Solana crank protocol: the buyer posts a task with a per-crank SOL reward and any anonymous signer may execute it, so firing is time-only, but the executor set, the due-condition and the failed run are all public chain state — and a task can return its own successor, keeping a conditional loop entirely onchain. It holds that rank under an affiliate-blind methodology scored across 4 published, weighted criteria — the code that ranks providers physically cannot read affiliate payouts (CI-enforced), so a payout can't move a rank. The verdict re-computes on every fee change, incident, or regulatory action; the full reasoning and the audit receipt are under Methodology.
How you can lose money here, and what the ranking scores
- Control failure: a key or vote changes the rules, freezes or mints.Scored by What can fire the call, against what target, and who can check the condition was true · 28% (TukTuk (Helium) 8/10, KeeperHub 6/10, Reactive Network 8/10)
- Liveness failure: the operator stops, censors you or loses data.Scored by Whether a run that never happened is visible, or the job just goes quiet · 24% (TukTuk (Helium) 7/10, KeeperHub 4/10, Reactive Network 7/10)
- Execution failure: you get a worse price, later, or nothing.Scored by The lateness the vendor will put in writing, and the conditions under which it declines to execute · 18% (TukTuk (Helium) 6/10, KeeperHub 7/10, Reactive Network 5/10)
- Exit failure: you cannot get out at par, on time, or with what is yours.Scored by Whether the job survives the vendor: who else can turn the crank, and what end-of-life is published · 30% (TukTuk (Helium) 8/10, KeeperHub 6/10, Reactive Network 2/10)
Every failure family that applies to this category is scored.
FAQs
4 questions readers ask before choosing automation & keepers.
Frequently asked
Questions people ask before choosing keepers
How would I know if my job silently stopped running?
On the evidence here, you would not be told. Zero of the seven document an alert that fires when a scheduled run does not happen, and the absence was established by exhausting each vendor’s own documentation rather than by spot-check — on Keep3r the words “notification”, “alert”, “monitor” and “webhook” return zero hits across the corpus. This is the category’s signature failure and the reason to read the visibility axis before the price: a missed run produces no transaction, no revert and no error, so the only possible evidence is a record of an absence. Four of the seven at least leave a chain-reconstructible history a third party can audit without the vendor’s cooperation; the rest keep it inside a dashboard behind tiered log retention.
Is Chainlink Automation still a safe default?
Not today, and this is the clearest case in the pool of a product that looks alive to every check short of an event scan. Its registry emitted its last UpkeepPerformed on 5 August 2026 and none since, across full block coverage — while getState() still answers normally, reports paused=false, and the contract still holds over 19,000 LINK. Its own app says “Chainlink Automation is being deprecated”. The successor runtime genuinely is executing, but you cannot deploy to it without a human approving your request, it carries an Early Access notice, and no price is published anywhere. It is marked as sunset here, so it ranks below every operating product.
What does “decentralised execution” actually survive?
Two of the seven. Only Keep3r and TukTuk let a stranger turn the crank without asking anyone: Keep3r’s documentation states that “To become a keeper, you simply need to call bond(address,uint)”, with zero allowlist or whitelist hits across 41 documentation pages. Everywhere else the executor set is the vendor’s, so “decentralised” describes the network the job runs on rather than the party that decides whether it runs. That distinction is what the heaviest axis measures, and it is why the ranking here disagrees with brand recognition.
Will anyone tell me how late a call can land?
No. Zero of the seven publish any bound on the interval between the condition becoming true and the call landing — the one quantity the category exists to control. Six of the seven publish schedule granularity instead, which is a different thing: a thirty-second cron resolution says how finely you may express a schedule, not how long the network may take to honour it. Treat a granularity figure as a specification of the request, never as a guarantee about the response, and read the conditions under which each vendor declines to execute at all — that half is unmarketed and, where it is undisclosed, lateness is unbounded.
Free advisor·No signup needed
Still unsure? Get your best keepers pick
Answer a few quick questions and get one clear recommendation based on how you actually plan to use crypto — then review the evidence before deciding.
No signup·Free first pass · Private·No spam · No account
Not financial advice · Independent · Always do your own research
Best picks
Best automation & keepers in 2026
Weighted on whether the job survives the vendor: who else can turn the crank, and what end-of-life is published, what can fire the call, against what target, and who can check the condition was true, whether a run that never happened is visible, or the job just goes quiet, and the lateness the vendor will put in writing, and the conditions under which it declines to execute, in that order. THE FAILURE THIS CATEGORY EXISTS TO PREVENT IS INSTRUMENTED BY NOBODY — 0 of 7. Not one vendor documents an alert that fires when a scheduled run does not happen, and the absence was established by exhausting each vendor's own corpus rather than by spot-check. Keep3r: 'notification', 'alert', 'monitor' and 'webhook' return zero hits across all 41 pages indexed at https://docs.keep3r.network/llms.txt.
Best overall
TukTuk (Helium)
An open-source Solana crank protocol: the buyer posts a task with a per-crank SOL reward and any anonymous signer may execute it, so firing is time-only, but the executor set, the due-condition and the failed run are all public chain state — and a task can return its own successor, keeping a conditional loop entirely onchain.
Data checked Sep 2026
An open-source Solana crank protocol: the buyer posts a task with a per-crank SOL reward and any anonymous signer may execute it, so firing is time-only, but the executor set, the due-condition and the failed run are all public chain state — and a task can return its own successor, keeping a conditional loop entirely onchain. Strongest on what can fire the call, against what target, and who can check the condition was true (8/10): Firing is time-only: the TriggerV0 enum holds Now and Timestamp(i64), and a separate cron program queues tasks on a schedule. A task can call any instruction on any program, and RunTaskV0 checks the due-condition onchain ("task.trigger.is_active()"), so anyone can replay it. Weakest on the lateness the vendor will put in writing, and the conditions under which it declines to execute (6/10): No SLA, uptime figure or check cadence is published; the homepage promises tasks "run on time, every time". The docs state the decline conditions: the reward must exceed the crank cost or "crankers will not be incentivized to run your task", and a cron that runs out of funding leaves the queue. Published price: No rate card, subscription or vendor invoice exists; the only price mechanics are on https://www.tuktuk.fun/docs/overview, fetched 2026-09-28 and unchanged since August: "Creators of Task Queues set their payment per-crank turn in SOL.
Best for: What can fire the call, against what target, and who can check the condition was true — 8/10
Browse this network
MS
Written and reviewed by Mathias Siemonsmeier, Founder
Not financial advice · For informational purposes only · Always do your own research