Method & limitations · updated November 4, 2026
What the analyzer can tell you.
Relay Rescue inspects files in a saved Relay export. Its findings help you decide what to rebuild and what to test. They are evidence from an archive, not a live check of your accounts or proof that a replacement workflow works.
Which files become an inventory
The parser looks for manifest.json, including inside a top-level folder, and recognizes workflow, sequence, MCP-server, and table collections. It groups associated files using their exported folders. Unrecognized structures and missing artifacts need manual inspection; an empty result does not establish that your archive contains no useful information.
Within an object's folder, definition selection favors workflow, sequence, definition, structure, or MCP-server JSON names. Run-history files are excluded from that selection. When several candidates remain, larger files are considered first. A selected file can still be the wrong description for a nonstandard export. Compare the object name, definition and file list against your original records.
Text or Markdown files can supply the build prompt; filenames containing “prompt” or “build” are preferred. That text describes intent. It is not an execution trace. Run/history JSON or CSV files supply evidence that history was exported; their presence does not prove successful runs or matching outputs.
The score measures available evidence
The interface's evidence score is a fixed checklist capped at 100. It is not a migration success rate, a compatibility score, or a recommendation to switch on the replacement.
| Workflow, sequence or MCP-server evidence | Points | Interpretation |
|---|
| Starting score | 25 | Baseline only, even when evidence is absent |
| Readable definition | +30 | Structure was selected, not executed |
| Build prompt present | +25 | Intent text is available |
| Run-history file present | +10 | A file was found, not verified as a successful run |
| Recognized app reference | +5 | A known name occurs in the source text |
| Detected steps | +5 | A step array or names were detected |
Tables use a different checklist: baseline 25, plus 65 for a detected table CSV, plus 10 if other supporting files exist. This does not validate CSV completeness, row counts, relationships, or destination storage.
Worked example: a workflow with a definition, prompt, recognized app and steps but no run-history file scores 90: 25 + 30 + 25 + 5 + 5. The missing-history warning still matters. A workflow scoring 100 can still have approval, credential, or branching risks; those warnings do not subtract points.
Detection is deliberately limited
App names and steps
App detection matches a fixed list of aliases against strings in the definition and prompt. A Slack mention in an instruction can be counted even if no Slack action exists. An unfamiliar app can be missed. Step count uses the largest recognized steps, nodes, actions or operations array, falling back to collected names. It is not a graph traversal or a billing estimate.
Branches, approvals and AI
Keywords in the definition and prompt flag potential human review, AI and webhook behavior. Branch count counts matching keys or string values, so one real branch can produce several matches. Treat these as prompts to inspect the source, not a faithful execution model. Screenshots and business rules known only to your team may contain requirements the scanner cannot see.
Turn a warning into a test
| Finding | Before rebuilding | Before activation |
|---|
| No run history | Create sanitized examples with expected outputs and an owner who can approve them | Compare destination output against each example; file presence alone is insufficient |
| Human review | Record who can approve, reject, time out and reopen the request | Test all four paths, including repeated approval clicks |
| Branching | Write the predicate and fallback for each path | Test true, false, empty, missing and unexpected values |
| Credential-shaped field | Identify the actual connection owner without sharing secrets | Reauthorize with appropriate permissions and test expired access |
A generated packet is a handoff specification. It cannot reconnect accounts, create a working n8n/Make/Zapier import, execute test cases, recover a deleted account, or guarantee equivalent behavior. Keep the replacement inactive until its owner accepts the results and has a rollback plan.
Data handling and safe sharing
The archive is read in memory in the browser tab. Relay Rescue does not upload workflow contents or generated packets. Optional aggregate usage and Cloudflare traffic measurement are separate; controls and collected signals are explained in the privacy notice.
Credential-shaped field detection and report redaction are pattern based. They are not a comprehensive secret or personal-data scanner. Review every generated file before giving it to a consultant or AI service: prompts, labels and business examples may still contain confidential information. Processing a large compressed archive can exhaust browser memory. Use only exports you trust and keep an untouched backup.
Who maintains Relay Rescue?
Relay Rescue is an independent tool maintained by Ethan Yu. It is not affiliated with Relay.app, n8n, Make or Zapier. The analyzer and generated packets are free; the optional $9 rebuild kit provides offline worksheets and checklists. Purchasing it does not buy implementation or a successful migration.
Report a documentation error or unsupported archive layout to support@relayrescue.app. Describe the issue and, if useful, filenames with identifying information removed. Do not send an export, credentials or customer data. We cannot promise recovery or support response times.
The synthetic n8n walkthrough demonstrates the process with invented data; it is not evidence of a customer outcome. The sample lets you inspect the generated artifacts before opening your own files.