Your APIs, checked every minute. From inside your network.
A schedule runs a request, a folder or a whole project on a cadence — every request with its scripts and its checks, exactly as Send does on your desktop. Sonda Server runs it on a box of yours, so it reaches the APIs only your network reaches, and nothing of a run ever leaves it. When it breaks, the people who need to know hear it. When it recovers, they hear that too.
A schedule
Every request, every check. Kept where the team reads it.
A run is a record in the team store, signed by the server and sealed under the project's key: whoever opens the project reads its runs, and nobody else does.
Request by request
Status, time, size and the checks' verdicts for every request, shown as the runner shows them. A request that failed keeps its response for diagnosis — 64 KB a body, 8 MB a run.
Run now
One run out of its cadence, after a confirmation, within a minute. A paused schedule runs once and stays paused. The run lands in the list as the server writes it.
The board
One page for the workspace: every schedule the person may see, failing first, with how many runs in a row it has failed. A project whose last run failed is marked on the Projects page.
Trends
A bar per run, its height the duration, its color the verdict. The success rate, the average and the slowest run, from the newest 30 runs, on the board and on the project's page.
A server started again
It knows where each schedule was from the runs in the store. One run at a time per schedule; slots missed while the server was down are not made up — one run, then on from there.
What a record never keeps
No address as it went out — the URL resolved, a key in its query. Every secret value masked in every text of the record and of the alerts: a check's reason, a console line, a response's headers and body.
Told when it breaks. Told when it's fixed. Not every minute in between.
The server sends on the changes, read from the runs themselves, so a restart never loses count.
Failed
When the failures in a row reach the threshold: one for the first failure, more so a flaky endpoint does not wake anyone over one blip. A refused run counts — the schedule did not run.
Recovered, still failing
Recovered once, when a run is fine again after an alert went out. Still failing every N failures while it keeps failing, or never. Each run says what went out for it.
By mail
Through the organization's own mail server, handed to Sonda Server sealed for its key. Plain text: the project, the schedule, the failed requests and the checks that did not pass. No body, no header, no value, no link. Up to 20 addresses.
By webhook
A POST of JSON with the event, the run and the failed requests, signed with HMAC-SHA256 when a secret is set. Set by administrators, and it never follows a redirect.
The summary
A workspace's digest by mail, daily at a time or weekly on days, set by its administrators: failing now first, then the worst success rate, then the paused and the ones that did not run — each with its runs, rate, average, slowest and alerts.
Inside your network
The mail goes to your mail server, the webhook to the address you give, the runs to your store. Nothing of it reaches LockFlare.
Sign in first. Fetch the list. Run it for each one.
An advanced schedule sends sources before the target — requests of the project — and reads their JSON answers into the variables the target uses.
Sources
Up to five requests sent before the target, each through the same engine: its folder's auth and scripts, the environment, what the sources before it filled. Up to 20 variables each, read from the answer by path.
The loop
One source can loop the target over an array of its answer: once per element, up to 500, with loopIndex counting from 1. An empty array is a good run with nothing to run over.
A source that fails
No 2xx, no JSON, or a path that finds nothing: the run is refused, the record says which source and why, and the alerts count it. A source's answer is read and dropped — a sign-in's token is never kept.
A schedule gives nobody more than they have.
The server checks before every run, with the permission files as they stand now — not as they stood when the schedule was saved.
Schedule runs
One permission, per project: create, change, pause, remove, run now. A schedule belongs to the project, not to its author: any holder or an administrator changes or stops it. App runners never see the runs.
PermissionsSigned by its saver
Every save signs what the schedule runs with the saver's key, and the server runs nothing whose signature does not verify. The saver's Send is checked at every request the run sends; a request the saver may not send is named and left out.
Encrypted projects too
The server runs from a copy of the project sealed for its own key, written from the store and never from a computer — unpublished changes never reach it. Every file is checked against the project's signed head before a run.
The values, at the save
The shared environment and the Team secrets the saver may read, resolved once at the save and sealed for the server. A value the saver cannot fill is named on the page.
SecretsHidden stays hidden
A request hidden from the team never runs on a schedule, an administrator's schedule included. It is counted, never named.
Nothing from the server's disk
A request whose body is a file of someone's computer is skipped on the server and named. The server never puts a file of its own into a request.