Usage and monitoring

In the app

Settings → API keys shows, for every key: requests over time, error rate, the last time it was used, and its current rate-limit headroom.

This is where a key’s traffic becomes legible without an engineer. Two patterns are worth looking for. A key with no recent use is a credential nobody is watching, and is usually safe to revoke. A key with a rising error rate is normally an expired credential or a filter that stopped matching after something was renamed.

Programmatically

curl https://api.askylabs.com/v1/usage \
  -H "Authorization: Bearer $ASKY_API_KEY"

{
  "data": {
    "period": { "start": "2026-08-01", "end": "2026-08-12" },
    "rate_limit": { "limit": 300, "remaining": 287, "reset_seconds": 41 },
    "keys": [
      {
        "key_name": "Data warehouse sync",
        "key_hint": "asky_sk_…yA2b",
        "request_count": 4820,
        "error_count": 3,
        "last_used_at": "2026-08-12T04:15:22Z"
      }
    ]
  },
  "request_id": "req_01J8Z3KD41"
}

The response covers every key in the workspace, not only the one making the request, so a single monitoring job can watch all of your integrations.

What we record

One record per request: the endpoint, the key, the outcome, and how long it took. We do not record response bodies.

Per-request records are retained for 90 days. Records of denied and failed requests are retained longer, because those are what a security review or an incident investigation needs. Daily per-key totals are retained indefinitely and are what the usage views are built from, so your history does not disappear when the detailed records age out.

Owners and admins can export this from Settings if you need evidence for an audit.

Monitoring a scheduled sync

A nightly sync fails quietly unless you watch for it. Four things worth alerting on:

Authentication failures. A 401 on a scheduled job means an expired or revoked key, and it will not fix itself. Alert a person on the first occurrence rather than logging it.

Sustained rate limiting. Occasional 429s handled by backoff are normal. A run that spends most of its time throttled means the job outgrew its budget; see rate limits.

A run that did not happen. The most common silent failure is a job that stopped being scheduled. Alert on the absence of a successful run, not only on errors. last_used_at in the usage response is a reliable heartbeat.

Zero rows. A sync that succeeds and returns nothing usually means a filter stopped matching, often because a topic or tag was renamed. It looks like success in every log.

Getting help

Include the request_id from the failing response. It identifies the exact request in our logs, which is the difference between us looking directly at what happened and asking you to narrow it down.

Never send us an API key. We will never ask for one, and no Asky email will ever contain one.