One plugin for your backend, one SDK for your apps — live traffic, errors, latency, consumers, uptime and alerts — on a dashboard that answers in milliseconds, not minutes.
Elysia · live todayFlutter · live todayHono · soonExpress · soonFastify · soonOpenTelemetry · soon
app.sentrinel.dev/trafficLIVE
Traffic
Consumers
Request logs
Uptime
Resources
Alerts
Errors
Performance
Requests
184k
Error rate
0.4%
p95
118 ms
Apdex
0.97
Requests · last 24 h
EndpointRequestsp95Errors
GET /v1/orders12.4k42 ms0.1%
POST /v1/payments8.1k118 ms1.2%
GET /v1/users6.7k31 ms0.0%
Consumer · share of traffic — last 24 h
acme-prod41% · 102k req
mobile-app27% · 67k req
partner-api18% · 45k req
staging-ci ▲ errors9% · 22k req
internal-cron5% · 12k req
TimeMethodPathStatusDuration
14:32:08.412GET/v1/orders?page=220038 ms
14:32:08.371POST/v1/payments201121 ms
14:32:07.988POST/v1/payments500642 ms
14:32:07.750GET/v1/users/881220024 ms
14:32:07.512PUT/v1/orders/5541/status20057 ms
All systems operational
api.yourapp.com — last 40 days99.98%
app.yourapp.com — last 40 days100%
CPU utilizationCurrent: 4% avg / 5% max
Memory usageCurrent: 499 MB avg / 978 MB max
Error rate > 1%p95 window · 5 minFIRING
p95 latency > 500 msall endpoints · 10 minOK
Uptime check failedapi.yourapp.com · 1 minOK
Quota above 80%monthly requestsOK
01 — Features
Deep monitoring for APIs and apps. Nothing else.
No kitchen sink. Sentrinel does one job — the sharpest possible view of your backend and the apps that call it — and does it properly. When it records a session or counts a funnel, it is to answer that same question, not to become an analytics suite.
Endpoint metrics & Apdex
p50 / p95 / p99, throughput and Apdex per endpoint, with banded charts and drill-down modals.
Error tracking
Fingerprinted, grouped issues with stack traces, assignment and the breadcrumb trail that led there.
Request logs
Search full logs — headers, payloads, and the caller's country, IP and serving host — down to a drag-selected slice of any chart.
Consumer analytics
See exactly which API clients drive traffic, errors and transfer — first-class, not an afterthought.
Uptime & alerts
HTTP checks with uptime strips, plus threshold alerts on error rate, latency and downtime.
Host metrics
CPU and memory for the machines running your apps, as a min–max band rather than a lying average — captured by the same plugin, no extra agent.
Postgres monitoring
Slow queries ranked by share of database time, wait events, blocking chains and table bloat. A collector runs next to your database — we never connect to it, and query literals are stripped before they leave your host.
Crash reporting
Flutter and browser crashes with the breadcrumb trail that led there. Fatal errors are written to disk before the process dies, so the report survives the crash and arrives on the next launch.
Custom metrics
Tokens, spend, queue depth, revenue — the numbers only your app knows, with count(), gauge() and histogram(). Increments fold in memory, so recording one per token costs a row every thirty seconds, not a write per call.
Session replay
Watch the seconds before an error. The browser buffers the DOM in memory and uploads only when something breaks, so a session that never fails costs nothing. Text and inputs are masked by default — you opt elements in, not out.
Funnels & retention
track() on the backend, the browser and Flutter feeds one set of funnels, retention curves and top screens. The same person's activity before and after they sign in stitches together, which is what makes a signup funnel measurable at all.
One timeline, phone to database
The SDKs send traceparent, so a tap in your app, the request it caused and the spans underneath land on a single waterfall instead of three disconnected searches.
+ Distributed tracing+ Time travel on every view+ Drag-to-zoom charts+ Multi-tenant orgs & quotas+ Light & dark themes+ Geo & client IP per request+ Funnels & retention+ Counters, gauges & histograms+ Session replay
02 — The differentiator
Know who is calling, not just how often
Most APM tools tell you your API is slow. Sentrinel tells you it's slow because one consumer is hammering one endpoint. Every request is attributed to the API client behind it.
Traffic, error and data-transfer breakdowns per consumer — the view Datadog and Sentry treat as an afterthought is first-class here.
Consumers — share of trafficLAST 24 H
acme-prod41% · 102k req
mobile-app27% · 67k req
partner-api18% · 45k req
staging-ci ▲ errors9% · 22k req
internal-cron5% · 12k req
03 — The engine
Handles your busiest day without breaking a sweat
Send us millions of requests a day — Sentrinel absorbs them all, keeps your dashboards answering in milliseconds, and cleans up old data automatically. You never manage storage, servers or retention jobs.
Smart sampling keeps your bill flat: routine traffic is sampled, but every error and every slow request is kept — and your metrics stay exact. Team workspaces, per-app keys and usage quotas are built in from day one.
✓ 10 apps✓ Unlimited dashboard users✓ Unlimited API consumers✓ Unlimited requests for metrics✓ 25M request logs / month · then $2 per 1M✓ 100M logs & spans / month · then $1 per 1M✓ Priority support
06 — FAQ
Frequently asked questions
Nothing on the request path. Metrics are aggregated in memory and flushed on a timer, so no request waits for a network call to us. If Sentrinel is unreachable the batch is dropped with a single warning rather than backing up your process.
Yes. Counters are computed in your process before sampling, so request counts and error rates stay exact at any sample rate — only the individual stored log rows are thinned. Errors and slow requests are never sampled out.
Only if you enable payload capture, and only after masking. Masking runs inside your process before anything is sent, so a masked field never reaches the network — it is redacted before it becomes a network packet, not after it arrives.
Elysia is first-class. Express and Next.js have their own adapters, Flutter and Dart have a native SDK, and anything that speaks OpenTelemetry can skip the plugin and export OTLP/HTTP straight to us.
Create an account, add an app, and drop the plugin into your code with the key it gives you. Data appears with the next request — there is no agent to install and no config file to write.
Yes. one `pip install` from our public GitHub repo, add one middleware, and every request, error and log line arrives correlated — a log line opens the request that wrote it. It has no runtime dependencies, so it cannot conflict with anything already in your project, and it is tested from Django 3.1 to 5.2 because the services most in need of monitoring tend to be the ones nobody has dared upgrade.
Yes. An MCP server and a CLI hand Claude Code, Codex, Cursor or any agent your issues, stack traces, request bodies, logs and traces, so "fix the top error in production" is a sentence you type. They run on an AI-agent key that can read exactly one app and write nothing, so the key in your agent's config is safe to lose.
Only its own job. Every key is bound to one integration — server, mobile app, database collector, OpenTelemetry, or AI agent — and is refused everywhere else. A key that falls out of a phone bundle cannot post a replay, reach the database collector, or read anything; a collector key on a database host cannot post application telemetry. Revoke it and the next call is refused.
It waits instead of disappearing. Run the durable ingest log and the API uses it automatically: batches are held there while the store is down and drained when it returns. If the log itself is down, batches go straight to the store. Ingest fails over in both directions, and the health endpoint says which path is carrying traffic.
Every request row carries the caller's IP and country and the host that served it, and both are filterable. The country comes from a header your edge already sets — Cloudflare, Vercel, Fastly or CloudFront — rather than from a GeoIP database bundled into your process. Behind no proxy at all the field stays empty, which is deliberate: an honest blank beats a wrong country.
Yes, and it only records what is worth keeping. The browser buffers the DOM in memory and uploads the seconds leading up to an error, so a session that never fails costs nothing and the recordings you keep are the ones you would actually watch. Text and inputs are masked by default — you opt individual elements in, not out.
Yes. count(), gauge() and histogram() push any number you care about, with labels to slice by. Increments fold in memory and ship one row per series per flush, so recording a metric per token is safe in a hot loop rather than a write per call. Tracing tells you why a call was slow; this tells you what it cost — they answer different questions about the same event.
Yes. track(), screen() and identify() exist on the backend, in the browser and in the Flutter SDK, and all three feed one set of funnels, retention curves and top screens. The anonymous id persists across app launches, which is what makes retention mean anything — without it every launch reads as a new person. What someone did before signing in stitches to their account once they do.
Yes — light, dark, or follow your system. It is stored per browser rather than per account, because the right answer usually depends on the screen you are sitting at.
The dashboard is blocked, but telemetry keeps arriving for a grace period, so paying restores an unbroken history rather than one with a hole in it. Nothing already collected is deleted. You can upgrade by card from Settings → Billing, or manage the subscription in the billing portal.
Every record knows its neighbours. A log opens the request it was written during; a request opens its trace waterfall; an error occurrence opens the exact request that produced it. You never copy an id into a search box.
Yes. A small collector runs next to your database, reads the pg_stat_* views, and reports slow queries, wait events, blocking chains, connection saturation, cache hit ratio and table bloat. Click a table for its columns and every index with its size against its scan count — the pair Postgres never shows together. It also watches the four things that stop a database without warning: transaction wraparound, sequence exhaustion, abandoned replication slots and checkpoint pressure, plus a configuration and security audit and the errors from the server log. Four alert rules are created with every database — wraparound, abandoned replication slots, connection saturation, sequence exhaustion — so an outage you could have seen coming reaches someone instead of waiting on a dashboard tab. Query text is shown in full by default — the statement you can paste into psql is the one worth having — with an opt-in setting that strips literals on your database host before anything is sent. It needs a read-only role holding pg_monitor — no superuser, which is what makes it work on RDS, Cloud SQL and Azure too.
No, and it cannot. The collector runs on your side of the network and holds the credentials; nothing here stores a connection string. Telemetry travels one way, out of your infrastructure, so a breach of Sentrinel is not a breach of your database.
No. Literals are stripped before anything is sent — WHERE email = '[email protected]' becomes WHERE email = ?. That happens in the collector, on your host, so the values never travel. It matters most for currently-running queries, whose text is fully substituted at the moment we read it.
Five minutes from now, you'll know exactly how your app behaves
Free for your first 100k requests. No credit card, no agents, no YAML.