Observability
From a spike on a chart to the bytes that caused it, in two clicks.
Most API tooling stops at an aggregate. Flintwake keeps the aggregate and the underlying requests in the same place, so a latency chart is a starting point rather than a conclusion.
- 30 daysSearchable request historyConfigurable per environment
- 1.8msMedian collector overheadMeasured at the edge, not at the origin
- 6Dimensions on every metricEndpoint, consumer, key, region, status, deploy
- 0Changes to your applicationCapture happens beside your API, not inside it
How it reads
Three layers, one click apart.
The distance between noticing a problem and understanding it is the whole product.
- 01
The number
A chart tells you p95 moved. That is where most tooling stops and where the argument starts.
- 02
The dimension
Flintwake splits the same number by endpoint, consumer, key, region and deploy — so the question becomes which one, not whether.
- 03
The request
Click through and you are reading the exact bytes: headers, redacted body, timing per phase, and the wake ID your support team can quote.
Charts
Latency and error attribution
Endpoints
Health per path template
Sort by throughput, any latency quantile or error rate. The sparkline shows the last twelve intervals.
| Endpoint | Trend | |||||
|---|---|---|---|---|---|---|
| GET/v2/catalog/items | 31,200 | 29ms | 63ms | 141ms | 0.04% | |
| GET/v2/accounts/{id}/balance | 26,100 | 18ms | 41ms | 88ms | 0.02% | |
| POST/v2/payments/intents | 18,400 | 62ms | 148ms | 312ms | 0.18% | |
| GET/v2/customers/{id} | 14,800 | 21ms | 48ms | 102ms | 0.61% | |
| PATCH/v2/subscriptions/{id} | 4,200 | 44ms | 96ms | 204ms | 1.42% | |
| GET/v2/reports/settlements | 860 | 410ms | 1820ms | 4400ms | 3.10% | |
| POST/v2/webhooks/endpoints | 120 | 51ms | 96ms | 188ms | 0.00% | |
| DELETE/v2/api-keys/{id} | 42 | 33ms | 52ms | 91ms | 0.00% |
Consumers
The view nobody else ships
Your dashboards are per-service. Your customers experience per-integration. This is the second one.
| Consumer | Plan | Requests | Errors | p95 | Quota |
|---|---|---|---|---|---|
| Northbank Payments | Scale | 14.8M | 0.11% | 128ms | |
| Halyard Retail | Scale | 11.2M | 0.28% | 96ms | |
| Cedarlift Logistics | Growth | 7.4M | 0.06% | 61ms | |
| Orrery Media | Growth | 6.1M | 2.44% | 214ms | |
| Pelham Freight | Starter | 4.9M | 1.18% | 402ms | |
| Tessellate Labs | Starter | 3.8M | 0.04% | 54ms |
Requests
The wake itself
Every aggregate above is one click from the requests underneath it.
- Requests · 24h48.2M▲ +6.4%
- p95 latency112ms▼ −9ms
- Error rate0.21%▼ −0.06pt
- Active consumers1,284▲ +37
- content-type
- application/json; charset=utf-8
- x-flintwake-wake-id
- wk_0c41f2a9
- x-ratelimit-limit
- 6000
- x-ratelimit-remaining
- 5842
- x-ratelimit-reset
- 38
{
"id": "pi_3QkL2xB",
"object": "payment_intent",
"amount": 24900,
"status": "requires_capture",
"created": 1789012458
}Capture rules
You decide what is kept.
Capture rules are a versioned file. Commit them to your repository, apply them on deploy, and review a change to redaction the way you review any other change.
- Request explorer
Filter 30 days of wakes by method, status, endpoint, consumer, key or region.
- Response inspector
Headers, body, timing waterfall and the wake ID your support team can quote back.
- Endpoint health
p50 / p95 / p99, error rate and throughput per endpoint, sorted by whatever is hurting.
- Live tail
A rolling stream for the twenty minutes around a deploy.
- Geography
Latency split by edge region so you know whether it is you or the distance.
{
"version": 3,
"capture": [
{ "match": "/v2/**", "bodies": true },
{ "match": "/v2/health", "capture": false }
],
"redact": [
"$.card.number",
"$.customer.email",
"$.*.tax_id"
],
"headers": {
"allow": ["content-type", "user-agent", "x-request-id"]
},
"retention_days": 30
}Point it at one endpoint and see whether the picture is better.
The quickstart takes four minutes and does not require a change to your application code.