Retry Schedule Planner

Overview

You tell us how a request failed and what your retry policy is, and we return the whole schedule: whether a retry is warranted at all, how long to wait before each remaining attempt, and the cumulative wait. Rate limits, timeouts, connection errors and 5xx responses are treated as worth retrying; client errors are not, because retrying a 400 unchanged just repeats it. A Retry-After you pass in raises the first wait, and every wait is capped by your ceiling. Jitter, when you ask for it, is derived from a seed you supply rather than a random number, so the same failure always plans the same waits. We compute the schedule only: no request is sent, nothing sleeps, and no clock is read.

Every HTTP client reimplements backoff slightly differently, so the same outage produces a different retry storm in each service and nobody can say how long a call will keep trying. Computing the schedule in one place makes the policy explicit, comparable across languages, and reviewable before it ships.

When to use it

Scope

Non-goals

• Does not send, resend, or probe any request
• Does not sleep, enqueue, or schedule anything
• Does not read a clock — waits are offsets, not wall-clock times
• Does not inspect the failed response body or headers for you
• Does not generate random jitter; jitter comes from your seed

Properties

Capabilities

Cost & billing

Flat rate per invocation

File handling

How we handle your data

Input schema

Output schema

API contract

curl -sS -X POST "$BASE/v1/execute" -H "Authorization: Bearer $KEY" -H 'Content-Type: application/json' -d '{"skillKey":"network.retry_policy_plan","input":{"policy":{"maxAttempts":4,"backoff":"EXPONENTIAL","baseDelayMs":1000,"maxDelayMs":60000},"failureType":"SERVER_ERROR"}}'

import { Squillify } from "@squillify/sdk";

const sq = new Squillify({ apiKey: process.env.SQUILLIFY_API_KEY });

const { output } = await sq.execute("network.retry_policy_plan", {"policy":{"maxAttempts":4,"baseDelayMs":1000,"backoff":"EXPONENTIAL","multiplier":2,"maxDelayMs":60000},"failureType":"SERVER_ERROR"});

Errors

Other limits

Limitations

• Does not send, resend, or probe any request
• Does not sleep, enqueue, or schedule anything
• Does not read a clock — waits are offsets, not wall-clock times
• Does not inspect the failed response body or headers for you
• Does not generate random jitter; jitter comes from your seed
• Performing the retries themselves
• Classifying a batch of queued job failures — use workflow.retry_dead_letter_plan
• Deciding retryability from a response body

How to call

POST /v1/execute (requires authentication)

{
  "skillKey": "network.retry_policy_plan",
  "input": {
    "policy": {
      "maxAttempts": 4,
      "baseDelayMs": 1000,
      "backoff": "EXPONENTIAL",
      "multiplier": 2,
      "maxDelayMs": 60000
    },
    "failureType": "SERVER_ERROR"
  }
}

Examples

{
  "policy": {
    "maxAttempts": 4,
    "baseDelayMs": 1000,
    "backoff": "EXPONENTIAL",
    "multiplier": 2,
    "maxDelayMs": 60000
  },
  "failureType": "SERVER_ERROR"
}

{
  "_meta": {
    "delaysFloored": 0,
    "failureType": "SERVER_ERROR",
    "delaysCapped": 0
  },
  "totalDelayMs": 7000,
  "retryable": true,
  "policy": {
    "maxAttempts": 4,
    "backoff": "EXPONENTIAL",
    "baseDelayMs": 1000,
    "maxDelayMs": 60000,
    "multiplier": 2,
    "jitter": "NONE",
    "jitterPercent": 0
  },
  "reasonCode": "RETRY_SCHEDULED",
  "attempts": [
    {
      "attempt": 2,
      "delayMs": 1000,
      "cumulativeDelayMs": 1000
    },
    {
      "attempt": 3,
      "delayMs": 2000,
      "cumulativeDelayMs": 3000
    },
    {
      "attempt": 4,
      "delayMs": 4000,
      "cumulativeDelayMs": 7000
    }
  ]
}

{
  "policy": {
    "maxDelayMs": 60000,
    "backoff": "FIXED",
    "baseDelayMs": 5000,
    "maxAttempts": 3
  },
  "failureType": "RATE_LIMIT",
  "retryAfterMs": 30000
}

{
  "_meta": {
    "delaysFloored": 1,
    "failureType": "RATE_LIMIT",
    "delaysCapped": 0
  },
  "totalDelayMs": 35000,
  "retryable": true,
  "policy": {
    "maxAttempts": 3,
    "backoff": "FIXED",
    "baseDelayMs": 5000,
    "maxDelayMs": 60000,
    "multiplier": 1,
    "jitter": "NONE",
    "jitterPercent": 0
  },
  "reasonCode": "RETRY_SCHEDULED",
  "attempts": [
    {
      "attempt": 2,
      "delayMs": 30000,
      "cumulativeDelayMs": 30000
    },
    {
      "attempt": 3,
      "delayMs": 5000,
      "cumulativeDelayMs": 35000
    }
  ]
}

Recommended use cases

• Show a caller the full wait schedule before their client starts retrying
• Apply one shared retry policy across several HTTP clients and languages
• Turn a Retry-After header into a policy-capped first wait

Avoid for

• Performing the retries themselves
• Classifying a batch of queued job failures — use workflow.retry_dead_letter_plan
• Deciding retryability from a response body

Related skills

Composable with

Safety & privacy

• Runs without calling any external service.
• Your payloads are never stored permanently.
• Telemetry captures metadata only — never your payload contents.
• We never train models on your payloads.
• No human reviews your payloads.

Tags