CrashGuard logo CrashGuard.io

CrashGuard.io

CrashGuard logo

Canary Oriented Workflow Monitoring

A canary is a deadline you set on a workflow instead of a log line you hope to see. You start one the moment a workflow kicks off, and resolve it the moment that workflow actually finishes — no matter how many systems it passes through in between. If the canary doesn't resolve before its deadline, CrashGuard knows the workflow is late or stuck, even if every individual system along the way reported success.

A canary created and resolved around a multi-system workflow A workflow passes through Order Service, Payment Service, and Fulfillment Service in sequence. Order Service calls the CrashGuard Engine to create a canary when the workflow starts, and Fulfillment Service calls the CrashGuard Engine to resolve that same canary when the workflow finishes. One canary tracks the whole workflow, regardless of how many systems it touches Order Service workflow starts Payment Service charge processed Fulfillment Service workflow finishes CrashGuard Engine tracks the canary create canary resolve canary

Checkpoints

A canary's deadline doesn't have to be a black box in between creation and resolution. Any system along the way can record a checkpoint — a named stage, with optional metadata — without resetting the canary's expiry. It's a lightweight progress marker, not a pulse: it tells you how far a workflow got, even if it never finishes.

A checkpoint recorded mid-workflow alongside canary creation and resolution A workflow passes through Order Service, Payment Service, and Fulfillment Service in sequence. Order Service creates a canary when the workflow starts and Fulfillment Service resolves it when the workflow finishes, while Payment Service records a checkpoint with the CrashGuard Engine partway through, without affecting the canary's expiry. A checkpoint records progress without resetting the deadline Order Service workflow starts Payment Service charge processed Fulfillment Service workflow finishes CrashGuard Engine tracks the canary create canary checkpoint resolve canary

Optional, anywhere

Any system in the workflow can record a checkpoint, not just the one that created or resolves the canary. A canary can have zero, one, or many checkpoints over its lifetime.

A timeline, not a status

Checkpoints are additive — each one is a timestamped stage name with optional metadata, stored alongside the canary. CrashGuard never overwrites or collapses them, so you get the full sequence of stages a workflow actually reached.

Pinpoints where it stalled

When a canary expires, its checkpoint history tells you exactly how far the workflow got before it got stuck — the difference between "it failed" and "it failed after payment cleared, before fulfillment."

Not sure? Add a verifier

By default, CrashGuard trusts the caller — resolving a canary is as simple as telling us it's done. A verifier raises the bar: it lets you attach workflow-specific logic that runs before a resolution is accepted, so "reported in" and "actually correct" aren't treated as the same thing.

  1. 1

    Configure it on a canary type

    Point a canary type at a verifier endpoint you control — a small HTTP service that knows what "successful" means for that specific workflow.

    Canary editor page showing verifier configuration A canary editor form for the canary type "order-completion-webhook" with a "Use a Verifier" checkbox checked, revealing a URL field set to https://api.mysite.com/canary-verify/order-completion-webhook Edit Canary Type CANARY TYPE order-completion-webhook TIMEOUT (HH:MM:SS) 00 : 00 : 00 Use a Verifier VERIFIER URL https://api.mysite.com/verifiers/order-completion-webhook CrashGuard will POST the canary's metadata to this URL before resolving it
  2. 2

    Resolution triggers the call

    When a canary times out, CrashGuard doesn't mark it failed right away. It first calls your verifier, passing along the canary's metadata — the same JSON payload you attached when the canary was created.

    Canary expiry triggers a verifier call, which checks WooCommerce and responds After 5 minutes with no resolution, the canary expires. CrashGuard's engine calls the verifier on the customer's internal API, and the verifier calls the WooCommerce API to get the order status before sending a response back to the engine. Canary: PENDING no resolution yet 5 min Canary: EXPIRED timeout reached CrashGuard Engine expiry detected, calls verifier calls verifier Verifier (your internal API) asked to confirm the order checks WooCommerce WooCommerce API order status lookup response CrashGuard calls the verifier, which checks WooCommerce, then responds back to the engine
  3. 3

    Your logic decides

    The verifier checks whatever actually matters — an order total matches, a payment cleared for the right amount, a file landed where it should — and returns a pass or fail.

    Canary expiry triggers verifier call, which checks WooCommerce and returns Extend, Trigger, or Resolve After 5 minutes with no resolution, the canary expires. CrashGuard's engine calls the verifier on the customer's internal API. The verifier calls the WooCommerce API to get the order status, then returns either an Extend verdict, a Trigger verdict, or a Resolve verdict back to the engine. Canary: PENDING no resolution yet 5 min Canary: EXPIRED timeout reached CrashGuard Engine expiry detected, calls verifier calls verifier Verifier (your internal API) asked to confirm the order checks WooCommerce WooCommerce API order status lookup "Extend" "Trigger" "Resolve" "Resolve" marks it healthy; "Extend" pushes the deadline out; "Trigger" fires the alert now
  4. 4

    Pass or fail, you find out

    A pass resolves the canary as healthy, same as if there were no verifier at all. A fail alerts you immediately, even though the workflow technically reported success — catching the cases where something completed but completed wrong.