Workflow monitoring and alerts

Monitor an automation from the Trigger through the final provider-side effect. FastHook exposes team-wide Workflow Activity, per-Workflow Audit, webhook request traces, Instant Trigger channel health, and channel alerts. No single signal proves end-to-end business success.

Monitoring layers

| Layer | FastHook evidence | Question it answers | | --- | --- | --- | | Trigger delivery | Source status, channel status, alerts, channel events, notification metrics | Is FastHook receiving or polling for the expected provider activity? | | Workflow execution | Activity and Workflow Audit | Did a run start, which version executed, and which Step first failed? | | Webhook infrastructure | Requests, events, attempts, and request trace | Was the request accepted, routed, transformed, and delivered? | | Provider operation | Step response status/output and provider logs | Did the external service accept and persist the intended change? | | Business outcome | Your application metrics or reconciliation | Did the automation produce the correct real-world result exactly once? |

Channel alerts currently cover Instant Trigger channel operation. They do not replace monitoring for failed Actions, direct Connection deliveries, provider-side asynchronous failures, or a missing business outcome.

Monitor Workflow Activity

Activity searches recent runs across every Workflow in the active team. Filter by:

• from and to, using ISO 8601, now, or relative values such as now-24h;
• source_id;
• status: queued, running, succeeded, or failed; and
• q, which searches request ID, Workflow name, and Source name.

Each row includes Workflow and Source identity, version, attempt count, run error, Step totals, compact ordered Step records, timestamps, response statuses, and normalized Step errors. The endpoint returns at most 100 rows per request and includes total for the complete matching query.

Start with failures over a narrow time window:

GET /v1/workflow-activity?status=failed&from=now-1h&limit=100
Authorization: Bearer fhp_...
x-team-id: tm_...

Then open the run in Workflow Audit. Use include_data=true only when redacted payload previews are required; metadata is available without loading preview data.

Define actionable checks

Recommended checks are operating-policy suggestions, not built-in FastHook service-level guarantees:

| Check | Suggested condition | First response | | --- | --- | --- | | Failed-run rate | Any unexpected failed run or a sustained increase | Group by Workflow, Source, Step, provider, and error_code. | | Queued/running age | Older than the normal execution plus retry or Delay window | Check the current Step, Delay, lease recovery, and queue retry state. | | Trigger silence | Expected business events are absent | Compare provider activity, Source channel state, and last notification/run times. | | Instant channel error | channel.status=error or an active alert | Inspect last_error, failure count, expiration, and channel events. | | Polling fallback | channel.status=fallback | Confirm coverage, event latency, duplicates, and the Instant restoration window. | | Provider throttling | Repeated 429 responses or retryable provider errors | Reduce concurrency/traffic and honor provider retry timing. | | Business mismatch | FastHook success but expected provider object is absent or duplicated | Reconcile using stable business identifiers and provider logs. |

Do not alert on every retry attempt as a separate incident. A retryable Action can temporarily return the run to queued; page when the age, volume, or final failure threatens the business objective.

Instant Trigger alert delivery

Team channel-alert settings support email and Slack:

• email is enabled by default;
• Slack is disabled until a valid https://hooks.slack.com/services/... webhook is saved;
• the default notification cooldown is 60 minutes;
• cooldown can be configured from 5 minutes through 10,080 minutes; and
• Google notification-silence detection defaults to 24 hours and can be configured from 1 through 720 hours.

Email alerts are sent to as many as ten team memberships whose role is owner or admin and whose email is not a local demo address. Delivery is recorded as sent, failed, or skipped. Email can be skipped when the deployment has no email binding or no eligible recipient.

Slack webhook credentials are stored using the provider-credential encryption mechanism. Alert deliveries expose their transport status and error message in channel events, so a failed alert transport can be diagnosed separately from the Trigger failure.

Repeated occurrences update the same active alert by Trigger and code. Notifications respect the team cooldown, while the occurrence count and last_seen_at continue to update. Successful channel recovery resolves provision and renewal alerts.

Notification-silence scope

The current silence detector is specific to enabled Google Instant channels that:

• remain in Instant runtime mode;
• have an active channel;
• have received at least one prior notification; and
• have not received another notification within silence_alert_hours.

The alert code is notification_silence. A new Google notification resolves that alert. Absence of a silence alert is not proof that every provider is producing expected events; maintain a business-level expected-volume or reconciliation check for other Triggers and for channels that have never received a first notification.

Monitoring cadence

For production automations:

1. continuously route actionable Instant channel alerts to an owned inbox or Slack channel;
2. review failed Workflow Activity at an interval appropriate to business impact;
3. compare event counts with the provider or system of record;
4. review fallback, restoration, renewal, duplicate, and latency metrics after provider or permission changes;
5. test alert delivery and escalation ownership periodically; and
6. keep request IDs, run IDs, Source IDs, Workflow versions, and provider object IDs in incident evidence.

Continue with Instant Trigger health and recovery and the incident response runbook.