2026-11-11, Engineering · Tutorials

AI engine status monitoring: pause when an engine is down

A monitoring pipeline sends prompts to several engines on a schedule. When one engine stops answering, the requests for it fail. They are not charged, but your report for that slot has a hole, and retries pile up. This post shows the three ways to see an engine’s state and how to pause and resume a pipeline with them.

GET /v1/engines

GET /v1/engines lists each engine you can call, whether it is down or up now, and how many of its newest finished requests answered. The call is free. The SDKs call it with engines(), and the MCP server has an engines tool.

An example response:

{
  "windowRequests": 30,
  "engines": [
    { "taskType": "CHATGPT", "name": "ChatGPT", "status": "up", "successRate": 96.7, "yourSuccessRate": 100, "yourRequests": 12 },
    { "taskType": "PERPLEXITY", "name": "Perplexity", "status": "up", "successRate": 100, "yourSuccessRate": 100, "yourRequests": 0 }
  ]
}

A rate with no request behind it is 100, since nothing failed. Check yourRequests before you trust yourSuccessRate. A request that failed because of the request itself, such as an invalid payload, is not counted.

An engine is down from the moment almost none of everyone’s recent requests answer until most of its newest ones answer again. The rates are refreshed about once a minute. See engine status.

engine.down and engine.up webhooks

Owners and developers can set one engine status URL on the Webhooks page of the dashboard. It gets an engine.down event when an engine goes down and an engine.up event when it answers again, under the same condition as status above:

{
  "type": "engine.down",
  "engine": "CHATGPT",
  "name": "ChatGPT",
  "at": "2026-11-07T10:15:00.000Z",
  "startedAt": "2026-11-07T10:15:00.000Z",
  "endedAt": null,
  "successRate": 3.3
}

This is the example from the webhooks docs. startedAt names the outage. at is when the engine went down or came back.

Events are signed, retried and logged like task deliveries, so they can arrive twice or out of order. The docs give the rule: deduplicate by type, engine and startedAt, keep the event with the newest startedAt, and within one outage let engine.up win over engine.down. A URL set while an engine is down gets that outage’s engine.down too. The dashboard can send a test engine.down, marked "test": true.

The status page

/status/ shows each engine’s success rate and typical answer time over its latest requests, plus a list of incidents with their start and end. The same data is at /status.json, and /status.xml is an RSS feed. Use the page for people and the API or webhook for code.

Pause and resume a pipeline

1. Before a scheduled run, call GET /v1/engines and leave out tasks for engines that are down. Record them as skipped, not as missing data.
2. On engine.down, stop submitting tasks for that engine. Tasks already queued for it can stay: failed requests are not charged. To drop everything waiting, DELETE /v1/async/queue removes all of your queued tasks on all engines and releases what they reserved. Running and finished tasks stay.
3. On engine.up, resubmit the skipped and failed slots. A failed task holds its idempotencyKey for 24 hours after it fails, so add a suffix such as :retry1 to the key of a resubmitted task.

This Python sketch applies rule 1 to a batch and keeps engine state from webhook events:

import os

import requests

API = "https://api.answerline.dev"
HEADERS = {"Authorization": f"Bearer {os.environ['API_KEY']}"}

engine_state = {}  # taskType -> {"startedAt": str, "up": bool}


def engines_up():
    r = requests.get(f"{API}/v1/engines", headers=HEADERS, timeout=30)
    r.raise_for_status()
    return {e["taskType"] for e in r.json()["engines"] if e["status"] == "up"}


def submit(tasks):
    up = engines_up()
    ready = [t for t in tasks if t["taskType"] in up]
    skipped = [t for t in tasks if t["taskType"] not in up]
    for i in range(0, len(ready), 500):
        r = requests.post(f"{API}/v1/async/task/batch", headers=HEADERS, json=ready[i : i + 500], timeout=60)
        r.raise_for_status()
    return skipped  # store these and resubmit after engine.up


def on_engine_event(event):
    # Call after verifying the Webhook-Signature header (see the webhooks docs).
    if event.get("test"):
        return
    current = engine_state.get(event["engine"])
    if current and event["startedAt"] < current["startedAt"]:
        return  # an older outage
    same_outage = current is not None and current["startedAt"] == event["startedAt"]
    up = event["type"] == "engine.up" or (same_outage and current["up"])
    engine_state[event["engine"]] = {"startedAt": event["startedAt"], "up": up}

startedAt values share one ISO 8601 format, so comparing them as strings orders them by time. Keep engine_state in your database, not in memory, if more than one worker reads it.

Pitfalls

• DELETE /v1/async/queue clears every engine’s queue, not one engine’s. Use it when you want to stop the whole run.
• An engine with few requests behind it can show a high successRate that says little. Read windowRequests and yourRequests with the rate.
• A slot that failed during an outage is a gap in a time series. Mark it as an outage in your reports so a drop in brand mentions is not read as a change in the answers.

GET /v1/engines lists only the engines that are served. Each one’s fields and targeting are on its page: ChatGPT, Gemini, Perplexity, Copilot, Grok, Google AI Mode, Google Search and Google News.

Next step

A new account gets 100 free requests, and GET /v1/engines is free. Set an engine status URL on the dashboard Webhooks page and send the test event to your handler. Field reference: webhooks.

Keep reading