FlowynBETA
LoginSign up
Observe

Know when your APIs and scheduled processes stop working.

Flowyn checks endpoints on an interval, waits for heartbeats from your jobs, asserts on API responses, opens incidents on repeated failure, records recovery, and groups repeated failures into one issue.

Start building Read the docs
Checking every 60s
test
GETapi.example.com/health
Healthy
last 16 checks · interval 60slatest 184 ms
12 consecutive passing checks. Flowyn requests the URL, records status and latency, and does not touch your API.
Problem

What teams build again and again

Uptime pings tell you a URL answered. They do not tell you the nightly job silently stopped, that the API returns 200 with a broken body, or that the same failure has happened 27 times since midnight.

What Flowyn provides

  • 01HTTP/HTTPS monitors on a fixed interval with latency history
  • 02Heartbeats for cron jobs, workers, and agents
  • 03API checks with status, header, body, and latency assertions
  • 04Incidents opened on repeated failure and closed on recovery
  • 05Issues: repeated failures grouped with a count and a sample
Behavior

What exactly happens

At the product-contract level. This is what your application and your agent can rely on.

  1. 01

    Create

    A monitor requests the URL every interval and stores the result with status and latency.

  2. 02

    Check

    Three consecutive failed results open an incident.

  3. 03

    Incident

    A later passing result closes the incident and records the recovery.

  4. 04

    Recover

    Failures with the same fingerprint across events, jobs, files, and monitors become one issue with a count and a sample.

Stateswaitinghealthydegradedfailingpaused
Capabilities

Everything around the observe operation.

POST /v1/monitors

HTTP checks

A name, method, URL, interval, and assertions go in. Check results with status and latency, plus incidents on repeated failure, come out.

Explore POST /v1/monitors

Heartbeats

Your process pings Flowyn after each run. A ping missing for twice the interval is recorded as a miss, and repeated misses open an incident.

Explore POST /v1/monitors

API checks

A method, URL, interval, and assertions go in. Pass or fail, with status, latency, and evidence, comes out.

Explore GET /v1/issues/{fingerprint}

Issues & diagnostics

Stored failures from files, events, jobs, or monitors go in. An issue group with an occurrence count, first and last seen times, and a sample comes out.

Explore
API example

One request. One resource you can read back.

Use an Idempotency-Key on durable create calls. Exact schemas are in the docs and OpenAPI.

For coding agents

An agent can create a monitor for every endpoint it deploys and read GET /v1/monitors/{id}/results and /incidents for status, latency, and open incidents. GET /v1/issues/{fingerprint} returns a grouped failure instead of raw logs.

POSThttps://api.flowyn.dev/v1/monitors201
curl -X POST https://api.flowyn.dev/v1/monitors \
  -H "Authorization: Bearer flw_test_••••" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: monitor-prod-health" \
  -d '{
    "name": "Production API",
    "type": "http",
    "method": "GET",
    "url": "https://api.example.com/health",
    "interval_seconds": 60,
    "timeout_ms": 5000,
    "assertions": [
      {
        "source": "status_code",
        "operator": "equals",
        "expected": 200
      }
    ]
  }'

Also on Flowyn

Monitors & issues stays inside Flowyn's boundary: observe, verify, evaluate, execute bounded work, and report the result. The same account, API keys, and history cover every product.

Frequently asked questions

Does Flowyn fix the failing API?
No. Flowyn observes and reports. It records the failure, opens an incident, and tells you. It does not change your system.
How do heartbeats work?
You create a heartbeat monitor with an interval. Your process calls POST /v1/monitors/{id}/ping each run. If no ping arrives within twice the interval, the miss is recorded; three misses in a row open an incident.
What is an issue?
An issue is a group of stored failures that share a fingerprint. It carries an occurrence count, first and last seen times, and a link to a sample failure.

Start with monitors & issues.

Create a workspace, make your first call in the test environment, and inspect every attempt.

Start building Read the docs