API monitoring with scheduled tests and alerts

Schedules from every minute to weekly

Pick a schedule in the monitor dialog: every few minutes, every few hours, daily at a time, or weekly on a day, in your own time zone. The schedule is stored as a cron expression and evaluated on the server in UTC, so monitors run whether or not anyone has the app open. If you create monitors through the public API (POST /v1/monitors with an API key), you can pass cron expressions directly: five-, six- and seven-field expressions and macros such as @hourly are accepted. A monitor runs at most once a minute.

*/5 * * * *     every five minutes
0 9 * * 1-5     09:00 UTC on weekdays
@daily          once a day at midnight UTC

What a run does

Each run executes the collection (or a chosen list of up to 500 requests and folders, in your order) with an environment, running every pre-request and test script. Monitor settings include:

• retries (0 to 3) so a single network blip does not page anyone
• a per-request timeout and a delay between requests
• iterations and an optional data set (up to 1,000 rows) for data-driven checks
• whether to follow redirects and whether to verify SSL certificates

You can also run a monitor on demand with Run now, for example right after a deploy.

Alerts by email, Slack, Teams and webhook

Choose when to be notified: on every failure, on every run, or on recovery. Alerts go to up to 20 email addresses and, optionally, to a webhook URL. Webhook alerts are signed POST requests (monitor.completed, monitor.failed, monitor.recovered) with an HMAC-SHA256 signature in X-Swc-Signature, so your receiver can verify they came from us. To avoid alert storms, you can stop alerting after a number of consecutive failed runs until a run passes again.

Slack, Microsoft Teams and Discord. Paste an incoming-webhook URL from Slack (hooks.slack.com), Microsoft Teams (a Workflows "post to a channel when a webhook request is received" URL, or a classic connector) or Discord, and alerts arrive as chat messages instead: the monitor's name and result, request and test counts, the first failing tests with their errors, and a button that opens the run. No app to install.

// Verify a monitor webhook in Node
const expected = "sha256=" + crypto
  .createHmac("sha256", process.env.SWC_WEBHOOK_SECRET)
  .update(`${req.headers["x-swc-timestamp"]}.${rawBody}`)
  .digest("hex");
const ok = crypto.timingSafeEqual(Buffer.from(expected), Buffer.from(req.headers["x-swc-signature"]));

Results and history

Each monitor shows its success rate, average duration, failing streak and how many runs needed retries. The newest 200 runs are kept. Open a run to see every request with its status code, response time, size, test results and console output, filtered by request or iteration. Runs triggered by the schedule and by hand are labelled so you can tell them apart.

Team-friendly

Monitors live in a workspace, so everyone with access sees the same results. Failing monitors also appear in your notifications, and workspace webhooks can broadcast monitor.run.failed events to other systems.

Reliability report

The Reliability report (chart icon in the Monitors panel) covers the last 7, 30 or 90 days: overall pass rate, failed runs, monitor runs per day split into passed and failed, each monitor's pass rate with average and p95 run time and last failure, the requests that fail most with their last error, and the most active editors. Download it as text for a status update or a review. See Monitors, alerts and the reliability report.

How it works

1. Save your requests and tests in a collection in the app.
2. Create a monitor: choose the collection, environment and schedule, and add alert emails or a webhook.
3. Watch the results build up. Monitors need a free account and a cloud workspace, and targets must be publicly reachable.

A local monitor can run in the app while it is open and raise in-app alerts; scheduled server-side runs and email alerts need a cloud workspace.

Frequently asked questions

How often can a monitor run?

At most once a minute. In the app, choose a minutes, hourly, daily or weekly schedule; the API also accepts cron expressions.

Can I monitor gRPC or GraphQL endpoints?

Yes. Any saved request in the collection runs, including GraphQL queries and gRPC calls with their test scripts.

How do I avoid false alarms?

Set retries so a failed run is repeated before it counts, notify on failure and recovery only, and use the notify limit to stop repeated alerts during a long outage.

Where does monitor traffic come from?

From the Swastik Codes server. Monitors can only reach public addresses; private and loopback addresses are refused.