How Vela repairs itself
What starts a repair, what it does, and where it stops.
Know when to wait for the repair and when to step in.
Publish after verification. Otherwise, Vela explains the next step.
Your path, in three steps.
- 01
Vela identifies the cause
An expired session calls for reconnection. A changed site may need a new connector version.
- 02
The fix is checked
When repair is supported, Vela revisits the site and checks the new version before publishing it.
- 03
Read the reported outcome
Repairing means work is in progress. If it fails, the connector shows Repair needed: press Retry repair when you want another attempt.
Want to go deeper?
Open just the topic you need.
Overview
When a site changes, Vela rebuilds the connector from a fresh observation of the workflow, and the new version replaces the old one only once it passed its certification. One repair starts on its own; the next ones are yours to start.
What starts a repair
- A run of yours, or an automatic check, shows that the site no longer answers the way a healthy connector expects. That starts one automatic repair.
- You press Retry repair on a broken connector. There is no monthly limit; each press starts one repair.
An expired sign-in never starts a repair: Vela signs in again with the saved credentials, or asks you to. An invalid input, a timeout or a network error starts nothing.
The three steps
- 1
Restore access
Before anything else, Vela signs in with the saved credentials if the session is gone. If the site wants a person — a code, an approval — the repair stops and asks you to sign in.
- 2
Rebuild
Vela revisits the live site, performs the task as it works today and builds a new version from what it observed.
- 3
Certify, then replace
The new version must pass its certification. Until it does, the previous one keeps answering; if it does not, the connector shows Repair needed.
Repairing a connector that changes things performs the action once
To prove that a repaired booking, message or record still works, the repair performs it once on the site, under a test name. The email that reports the repair — successful or not — says exactly what was created so you can delete it. Your own requests are never replayed.
When Vela stops
| Situation | Why it stops | What you do |
|---|---|---|
| An action was sent and its outcome is unknown | Nobody can tell a booking that failed from a booking your customer now holds. A repair would drive the same flow again. | Look on the site itself, decide what really happened, then run it again yourself if needed. |
| The automatic repair did not fix it | Trying again on its own would repeat the same attempt at your expense. | Press Retry repair when you want another attempt, or rebuild the connector. |
| The site needs a person | A one-time code, an approval screen, a puzzle. No repair can pass those, by design. | Sign in once yourself; the next failure repairs it normally. |
| The account has no plan that includes repairs | Repairs run models and a browser; they are part of the plans. | Review the plan. |
What you see while it happens
- The connector shows Repairing, and the repair keeps running whether or not you stay on the page. It can take up to twenty minutes.
- You get one email when it ends: repaired, or what to do next. None when it starts.
- Every state change is in the connector's lifeline, with the reason.
What a repair costs you
Repairs are included in the plans and do not count as customer executions.
When a repair is not the answer
If the site removed the feature your connector used, no repair can invent it back. The honest outcome is a connector showing Repair needed and a decision for you: rebuild the task differently, or accept that this one is no longer possible.
Where to go next
- The life of a connector — the states a repair moves a connector between.
- Troubleshooting — symptom by symptom.
The same know-how, with separate access.
↗Your situation doesn’t match the guide?
Talk to the team ↗