Find the change behind failing requests, and roll it back

October 29, 2026

At 16:02 someone edits the mapping for the SMS provider and publishes. The edit renames the field that carries the phone number, the integration breaks, and the provider answers 422 to every appointment reminder. Usually the first sign is a patient who missed an appointment, followed by a morning of asking the team who changed what. In EchoRelay, the error-rate notice tells you requests are failing, the audit log shows the change that came first, and a rollback puts the previous revision back.

Hear it from the error rate, not from a patient

On the project's Notifications page, switch on Error rate is above your level. Choose the share of requests that may fail, from 1 to 100 percent, and the window it is measured over: 5, 15 or 60 minutes. You get one notice when the level is crossed and one when it is back under, once the window holds enough requests to judge, in the panel and by email.

It counts the failures you can fix: a target rejecting the mapped body, refusing the credentials or answering 404 at a wrong address, and a target that errors or times out. Unknown or expired keys, billing and capacity refusals, and faults on our side are left out, so a notice points at your configuration or a target.

The failed request shows what the provider answered

Open one of the failed requests in the request log. Each delivery attempt shows the provider's status, here a 422: the provider is up and refusing what it was sent. That rules out an outage before anyone opens the provider's status page.

The audit log shows who published what, and when

Open Audit in the project. Every change is a row with its time, the person who made it and where it came from: the panel, our REST API, an AI agent over MCP, or a scheduled job. The publish at 16:02, just before the first failed reminder, is there with a name on it. Secrets stay redacted in every row, so nobody copies the provider's token into a chat while investigating.

Roll back after you see what it will change

The line keeps its earlier published revisions. Pick the one before 16:02 and Rollback shows the changes it will make before you confirm, here the field name going back. Credentials keep their current values, so a token or password rotated since then is not undone. If someone publishes while you are looking, the rollback is refused and shows you the new diff, so it never overwrites a fix you have not seen.

From the next request on, reminders reach the provider again, and the error-rate notice sends its all-clear once the share drops back under your level. The reminders that failed stay in Held for retry with the 422 and the body that was sent, so you know exactly which patients to remind another way.

Over MCP, an AI agent has the same reads: the failed requests, the audit events and the revision history. It can show you the rollback diff and apply it once you agree. The same steps find a mapping edit that started sending an insurer's quote API a premium in pounds instead of pence.

What your team stops doing

Nobody spends the morning asking who touched the integration, and nobody reverts by hand under pressure. The time goes to the fix. The notifications guide sets up the error-rate notice, the audit log guide lists what each row records, and lines and revisions covers rollback.

Connect everything. Deploy nothing.

No credit card required.