API monitoring

API endpoint monitoring right on your work computer

Check backend endpoints on a schedule or in bulk with one click. Microkoi tracks uptime and response time, opens incidents and sends a system notification when an endpoint goes down and when it comes back.

The Microkoi monitoring section: a tree of monitors with status and uptime, stats for the selected monitor, a strip of recent checks and a response time chart by phase.

A monitor from an existing request

  1. 1

    Pick a request

    The monitoring icon on a request or folder in a collection, “To monitoring” in the editor, or “Monitoring” in the captured exchange panel.

  2. 2

    Set the conditions

    An interval from 20 seconds to a day, the number of retries and success conditions: status code, a JSON value, text in the body, a header.

  3. 3

    Keep working

    While the app is open, monitors check themselves, and a system notification tells you when something goes down or recovers.

Stats without a server or an account

Everything is computed on your computer and stored in the workspace database.

  • Bulk checks

    “Check all” or the check button on a folder polls many endpoints at once — handy right after a deploy to a test server.

  • Success conditions

    Status code, a value at a JSON path like data.items[0].status, text in the body and headers. The first failed condition becomes a clear reason for the outage.

  • Timing by phase

    A response time chart for an hour, a day, a week or a month, split into DNS, connect, TLS, waiting and download.

  • A year of uptime

    Uptime for 24 hours, 7, 30 and 365 days, the average and 95th percentile response time, and the last 60 checks.

  • Incidents and notifications

    Going down opens an incident and sends a notification; the first success closes it with the downtime duration.

  • Slow responses and certificates

    A warning when a response is slower than you set or the server certificate expires in fewer days than you set.

How it works

A monitor is a copy of a request

A monitor gets a copy of the request, so later edits in the collection do not affect it, and deleting the request does not break it. Environment variables like {{baseUrl}} and {{token}} are substituted on every check.

  • A collection folder becomes a monitor folder with the same nesting
  • A monitor is a file in the monitors folder, so you can hand it to a teammate through git
  • Check history stays on your computer

Five statuses and no false alarms

Up, degraded, retrying, down and paused. A monitor goes down only after an error repeats the number of times you set, with retries on their own interval.

  • Manual checks change the status but send no notifications — the result is already on screen
  • While the status stays the same, notifications are not repeated
  • The Monitoring item in the sidebar shows how many monitors are down

The full exchange of a failed check

For the first error of an outage, and whenever its reason changes, the whole request and response are stored. Open it in the exchange panel and send it to requests, copy it as a cURL command or turn it into a mock.

When checks run

Microkoi is a desktop app, so monitors run while the app and this workspace are open. Time when your computer was asleep counts as neither uptime nor downtime. Round-the-clock production monitoring is a job for a server.

  • The interval is at least 20 seconds with at most four checks at a time, so monitoring cannot become load on someone else’s service
  • A workspace from someone else’s repository does not start monitors on its own until you trust it

Questions and answers

How is Microkoi monitoring different from a monitoring service?

Checks run from your computer while the app is open, with no server or account. It is handy for watching a test server while you work and for checking a batch of endpoints after a deploy. For round-the-clock production monitoring you need a server.

How often can an endpoint be checked?

From once every 20 seconds to once a day. The lower limit keeps monitoring from turning into load on the server.

Where do notifications go?

To macOS system notifications: “down” when an endpoint fails and “up again” with the downtime duration when it recovers. Webhooks and messengers are not supported yet.

Can I check every endpoint right after a deploy?

Yes. “Check all” polls every monitor in the workspace, and the check button on a folder polls the monitors in it. Manual checks also work for paused monitors.

Try it on your own project

The beta is free and needs no sign-up. Download it, pick your project folder and start the proxy — your first requests will show up within minutes.

Version 0.9.0 · macOS, Windows and Linux · no sign-up