← All scenarios

Incident response

Turning an integration down needs a deploy

A downstream system starts failing at a rate that is not quite an outage, and the only lever anyone has is a release.

Operations teams that own a process

These are illustrative scenarios showing how the products are used, not customer case studies.

The same sequence, twice

The same sequence today, and with SynaptaGrid.

Today

  1. Dependency degrades
  2. Retries amplify it
  3. Fix lives in code
  4. Ship during the incident

With SynaptaGrid

  1. Dependency degrades
  2. Throttle that action live
  3. Runs wait instead of failing
  4. Lift the limit when clear

The situation

The integration keeps calling, the retries make it worse, and the fix — lower the rate, stop calling that one operation — lives in code. It has to pass review and ship while the incident is still running, and it gets reverted the same evening.

How it is approached

A connected system, or one single action on it, is paused, stopped or rate-limited while runs are in flight. Concurrency and request rate are overridden per action, with a live view of what is currently held back and one control that disables every integration at once. A step blocked by a rate limit waits and retries without spending one of its retry attempts.

What changes

The response to a degrading dependency is a control an operator uses during the incident, not a release. Runs already in flight stay on the version they started on and continue once the limit is lifted.