Skip to content

Operations

Operations are actions — outbound HTTP calls you configure once and execute on demand: trigger a CI pipeline, restart a service through its control API, page a runbook. Each action can run manually from the dashboard, automatically when a check changes state, or on a schedule. Every run is recorded, and the pipeline you trigger can report its own status and logs back, so the full story — dispatched → ran → succeeded — lives in one place.

Anatomy of an action

Field Description
name Display name
url Target URL (http/https, public hosts only)
method GET, POST, PUT, PATCH, or DELETE (default POST)
headers Key/value map — put secrets like API tokens here
body_template Request body; supports {{variable}} placeholders
trigger_type manual, state_change, or schedule
check_id Which check fires it (state-change trigger)
trigger_to_state Fire only on this state (down, degraded, up); empty = any
interval_seconds How often to run (schedule trigger, min 60)
timeout_ms Request timeout, 100–15000 (default 10000)

Secrets stay write-only

Header values are stored but never returned — reads show ********. When editing, leave the ******** value untouched to keep the stored secret, or type a new value to replace it. Keep secrets in headers, not in the body template (the body is returned as-is).

Creating an action

Operations → New action. Pick a trigger, add headers, write the body template, save.

curl -X POST https://api.wanepia.com/v1/actions \
  -H "Authorization: Bearer $WANEPIA_KEY" \
  -d '{
    "name": "Deploy on failure",
    "url": "https://api.github.com/repos/acme/platform/actions/workflows/deploy.yml/dispatches",
    "method": "POST",
    "headers": {
      "Authorization": "Bearer ghp_yourtoken",
      "Accept": "application/vnd.github+json"
    },
    "body_template": "{\"ref\":\"main\",\"inputs\":{\"reason\":\"{{entity_name}} is {{to_state}}\",\"wanepia_execution\":\"{{execution_id}}\"}}",
    "trigger_type": "state_change",
    "check_id": "<check-uuid>",
    "trigger_to_state": "down"
  }'

Triggers

Manual — the Run button in the dashboard, or POST /v1/actions/{id}/run. Executes synchronously and returns the result (status code, latency, response snippet) immediately. Optional body {"vars": {"key": "value"}} overrides template variables.

State change — attach the action to a check. When that check's entity transitions state (e.g. up → down), the action fires with the transition's context available as template variables. Remediation-style: redeploy when a service goes down, warm a cache on recovery.

Schedule — runs every interval_seconds (minimum 60). Useful for keep-alive pings, periodic cache refreshes, or nightly pipeline kicks.

Template variables

Placeholders in the URL and body template are substituted at execution time:

Variable Available Value
{{execution_id}} always ID of this execution — pass it to your pipeline so it can report back
{{action_id}}, {{action_name}} always The action itself
{{timestamp}} always RFC 3339 UTC
{{entity_id}}, {{entity_name}} state change The affected entity
{{check_id}} state change The check that transitioned
{{from_state}}, {{to_state}} state change e.g. up → down
{{transition_id}} state change Links the execution to the state transition

Manual runs can supply any variable via {"vars": {...}}. Unknown placeholders are left as-is.

Execution history

Every run — manual, triggered, or scheduled — writes an immutable execution record: dispatch status (success = 2xx), HTTP status code, latency, the first 4 KB of the response, and an error message when something went wrong. Blocked attempts (e.g. a template variable rewrote the URL to a private host) are recorded too, so nothing fails silently.

curl https://api.wanepia.com/v1/actions/<action-id>/executions \
  -H "Authorization: Bearer $WANEPIA_KEY"

Pipeline feedback

Dispatching a workflow usually returns immediately — GitHub answers 204 before your pipeline has done anything. To close the loop, the pipeline reports back against the execution that launched it:

curl -X POST https://api.wanepia.com/v1/actions/executions/$EXECUTION_ID/events \
  -H "Authorization: Bearer $WANEPIA_KEY" \
  -d '{"status": "running", "logs": ["checkout main", "build ok"]}'
  • status — queued, running, succeeded, or failed; shown as the Pipeline column in execution history (last write wins)
  • logs — plain text lines, appended in order; viewable by expanding the execution row in the dashboard

The pipeline learns its $EXECUTION_ID from the {{execution_id}} template variable — pass it as a workflow input, query parameter, or payload field when you configure the action.

GitHub Actions example

on:
  workflow_dispatch:
    inputs:
      wanepia_execution:
        required: false

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - run: |
          report() {
            curl -s -X POST "https://api.wanepia.com/v1/actions/executions/${{ inputs.wanepia_execution }}/events" \
              -H "Authorization: Bearer ${{ secrets.WANEPIA_KEY }}" -d "$1"
          }
          report '{"status":"running"}'
          ./deploy.sh && report '{"status":"succeeded","logs":["deploy complete"]}' \
                      || report '{"status":"failed","logs":["deploy failed, see CI"]}'

Limits: 100 log lines per request, 1,000 per execution, 2 KB per line. Hitting the per-execution cap returns 409 LOG_LIMIT.

Limits & permissions

  • Up to 50 actions per tenant, 20 headers per action, 16 KB body template.
  • Target URLs must resolve to public hosts — private/reserved addresses are rejected at create time and at execution time (after template substitution).
  • Creating, editing, and deleting actions requires the admin role; any member can run them and read history. Read-only API keys can only read.