Apity now runs as one service per client, opens long periods in a fraction of the time, has a completely new look, and tells you what changed without digging through logs.
Every client now has their own installation: one backend, one Postgres database and one storage bucket. The router, Redis, master database and separate frontend are gone, so there are fewer moving parts to run, pay for and debug.
Before7 componentsRemoved in 1.11After3 components
Same integration. The backend accepts POST /api/v1/logs and POST /api/v1/metrics with the same contract as the old router, so existing loggers keep working.
One domain. A single address now serves log intake, the API and the admin.
Batched writes. Incoming logs are buffered in memory and written to Postgres in one batch every 10 seconds. The buffer is flushed on shutdown, including during deploys.
Full logs in the bucket. Request and response bodies are gzipped and stored in the client’s own bucket.
Automatic cleanup. Logs, metrics, uptime records and stored bodies older than 90 days are removed automatically. Change the period with LOG_RETENTION_DAYS.
Simple setup. A new installation creates its own tables on first start.
Speed
A much faster admin
Long periods now read prepared hourly totals instead of scanning millions of log rows, and the queries that loaded whole tables into memory are gone.
15× faster
Month view on the dashboard
Before0.6 s
Now0.04 s
Measured on a test database
19× faster
Loading log filters
Before460 ms
Now24 ms
Measured on 500K log rows
7× less
Data read per log filter query
Before355 MB
Now50 MB
Measured on 2.4M log rows
5× less
Backend memory in production
Before943 MB
Now191 MB
Average. Peaks: 2 GB before, 398 MB now
34% less
Postgres memory in production
Before390 MB
Now257 MB
Average. Peaks: 1.26 GB before, 310 MB now
38% less
JavaScript on first load
Before1,041 kB
Now644 kB
Pages now load on demand
Production figures come from one client installation and compare the previous month with October 31 to November 2, 2026.
Hourly aggregates. Requests, errors and response-time histograms are rolled up per endpoint and hour every 5 minutes and kept for 400 days. Week, month and year views read them, and p95 stays within 0.1% of the exact value.
Work moved into the database. Filter values and percentiles are calculated in SQL instead of loading rows into the server. Filter lists read the last 7 days through an index.
Less to download. Every page is a separate chunk that loads when you open it, and the Inter font ships with the app instead of coming from Google Fonts.
Memory limits. The backend and the database run with fixed memory limits, so one heavy query can no longer inflate them without bound.
Redesign
A new admin, top to bottom
Every page, drawer and dialog was rebuilt on one design system. Colors, spacing, type and components now come from a single set of tokens, with a light and a dark theme that follow your system setting.
Every page, in both themesSample data
Light
Dashboard
Logs
Errors
Uptime
Activity
OverviewHealthy
Requests
1.28M
6.4%
p95 latency
412 ms
9.2%
GET/api/clubs200
POST/api/bookings201
POST/api/payments500
Dark
Dashboard
Logs
Errors
Uptime
Activity
OverviewHealthy
Requests
1.28M
6.4%
p95 latency
412 ms
9.2%
GET/api/clubs200
POST/api/bookings201
POST/api/payments500
New sidebar. Navigation is grouped into Traffic and Health, with search, notifications and an account menu always in reach.
Details in drawers. Logs, endpoints and users open in right-side drawers with tabs, and Esc closes only the top layer.
Consistent states. Loading, empty and error states look and behave the same everywhere.
Cleaner styles. Shared classes used to be redefined in 3 to 7 page stylesheets and overrode each other. Page CSS went from 12.9K to 5.2K lines.
Custom dropdowns. One component replaces every native select. It is never clipped inside cards, opens upward near the bottom edge, works from the keyboard, searches long lists and marks methods and statuses with colored dots.
Filters on any pageTry it
Method
Status
Period
New tools
The admin now points you to what matters
Until now the admin showed data and waited for you to look. These eight tools surface problems on their own and make it faster to get from a symptom to its cause.
Dashboard overview
The dashboard is now the default page and opens with the health of your API: status, requests, error rate, p95 latency, Apdex and active users, each with its change from the previous period.
What changed. See the endpoints that got slower or started failing, and open any of them in one click.
Fair comparisons. An unfinished period is compared with the same elapsed part of the previous one, so Monday morning doesn’t look like a traffic crash.
DashboardSample data
Overview
Degraded
vs. the same point last week
Requests
1.28M
6.4%
Error rate
0.42%
0.1 pp1.2K 5xx
p95 latency
412 ms
9.2%p99 1.2 s
Apdex
0.96
0.01Excellent
Active users
8.4K
3.1%
What changed
Endpoints that moved the most compared with the previous period
Slower endpoints
GET/api/clubs/:id/schedule240 ms → 410 ms71%
GET/api/matches180 ms → 265 ms47%
More errors
POST/api/bookings37 new 5xx
POST/api/payments/intent0.4% → 1.9%
Daily summary
A card at the top of the dashboard sums up yesterday in a few lines, so you know how the day went before opening anything else.
The whole day at once. Traffic, errors and p95 against the day before, the busiest hour, what got worse, uptime, alerts and your business metrics.
Any previous day. Step back through earlier days with the arrows, or collapse the card when you don’t need it.
A bell in the sidebar collects everything that needs attention, right inside the admin. Rules run every minute, and a problem closes itself once things recover.
Traffic. Logs stopped arriving, or traffic dropped well below its usual level.
Errors and speed. A spike in server errors, new 5xx on an endpoint, or responses slower than usual.
Availability and storage. An uptime check went down or recovered, or bodies aren’t being saved.
Reports. Suspicious activity was found, or the daily summary is ready.
Your call. Admins and owners can also resolve an active alert by hand.
Sidebar, bell iconSample data
Notifications
AllActive 1
Today
Spike in server errors4 min ago
8.4% of requests failed with 5xx over 10 min (212 of 2,530), mostly POST /api/bookings
OngoingResolve
Suspicious activity: User #2087 (demo_relay)52 min ago
Cloudflare proxy, IP switching · 640 requests, 14:00–15:00
Responses were slower than usual3 hr ago
p95 reached 1.4 s over 10 min; it’s usually 420 ms
Resolved after 22 min
Main API is back up5 hr ago
It was down for 3 min
Summary for October 3008:00
184,320 requests, 0.31% server errors, p95 398 ms
Suspicious activity
Every hour an analyzer checks the previous hour of logs per user and per IP, and stores what it finds with the evidence. The tab only reads those results, so abuse gets caught even when nobody is looking.
Nine signals. Too many requests, password guessing, path scanning, ID enumeration, Cloudflare relaying, IP switching, many accounts on one IP, bulk downloads and bursts of errors.
Three levels. Weak signals stay in the tab. Warnings and critical findings also send a notification, at most one per user or IP every 6 hours.
Tuned to real traffic. Normal bursts from a mobile app and everyday network changes don’t raise alarms. Each client is compared with the typical one in the same hour.
Built for review. Each finding explains what happened, why it looks suspicious and what to check. Mark it reviewed, ignore it, or add the user or IP to the trusted list.
ActivitySample data
Checked every hour·last check 14:00–15:00 at 15:03·next ≈ 16:03
User or IP
Risk
Reasons
Hours
Status
User #1042demo_botCloudflare
Critical67
ID enumeration700 IDs on /api/users/:idToo many requests1,500 req/h · ×250Cloudflare proxy100%IP switching12 networks
1
Open
198.51.100.7
Critical32
Access denied150 × 401/403
1
Open
203.0.113.50
Critical32
Scanning300 × 404
1
Reviewed
User #2087demo_relayCloudflare
Warning40
Cloudflare proxy100%IP switching13 networks
17
Open
User #3310demo_phone
Weak signal7
IP switching15 networks
1
Open
Business metrics
Count API responses as product numbers. A metric is an endpoint plus a status, so successful bookings can simply be POST /bookings with a 2xx response.
Funnels. Chain metrics into steps and see the conversion between them and overall.
Started for you. Apity suggests metrics from the endpoints it already sees in your traffic.
Instant history. Values come from the hourly aggregates, including periods from before you created the metric.
In the daily summary. Your metrics also appear in the card at the top of the dashboard.
Business metricsSample data
Successful bookings
12,480
8.2%vs. previous week
POST /api/bookings · 2xx
Failed payments
312
12.4%vs. previous week
POST /api/payments · 4xx/5xx
New sign-ups
1,860
3.1%vs. previous week
POST /api/auth/register · 2xx
From search to booking
4 steps
Overall25.9%1.4 pp
1Search clubs48,210
100%
54.6%from previous step
2Open schedule26,340
54.6%
57.4%from previous step
3Hold a slot15,120
31.4%
82.5%from previous step
4Successful bookings12,480
25.9%
User journey
An error log now answers the next question: what was this person doing? The Journey tab in the log drawer shows the same user’s requests around the one you opened. Anonymous requests are matched by IP.
Your window. See 5, 15 or 60 minutes before the request and 5 minutes after it.
Easy to scan. Errors are highlighted, the opened request is marked, and every row opens that log.
Log details, Journey tabSample data
User #1042 (demo_user)
7 requests·2 errors·5 endpoints
Before this request
5 min15 min60 min
19:02:11GET/api/clubs20084 ms
19:02:14GET/api/clubs/128/schedule200212 ms
19:02:31POST/api/bookings/hold200140 ms
19:02:48POST/api/payments/intent200380 ms
19:02:55POST/api/bookingsThis request5001.2 s
After
19:03:02POST/api/bookings5001.1 s
19:03:20GET/api/bookings/my20096 ms
Command palette
Press Ctrl K anywhere in the admin to get where you’re going without the mouse.
Pages and actions. Jump to any page, switch the theme or log out.
Endpoint search. Find an endpoint by part of its path and open it.
Open by ID. Type a number to open that log or user directly.
Ctrl K on any pageTry it
Endpoints
POST/api/bookings12.4K req
GET/api/bookings/my8.9K req
POST/api/bookings/hold15.1K req
DELETE/api/bookings/:id640 req
Logs
Search logs for “book”
Live logs
Turn on Live to watch requests as they arrive. The rest of the Logs page got sharper too, and pages now link to each other, so you can follow a problem without losing your place.
Shareable views. Filters and the opened log are in the URL, so any view can be sent as a link.
Copy a request. Copy any log as cURL, JSON or a link.
Focused numbers. The numbers above the table follow the endpoint you filter by.
Connected pages. Endpoints, errors, logs and users link to each other, and the endpoint list exports to CSV.
Smaller changes that make the numbers more trustworthy and the admin safer.
Storage alerts
The backend checks at startup that the bucket accepts writes and keeps tracking uploads. If they fail, a warning appears above every page and /status reports the error, so request and response bodies can’t go missing unnoticed.
Request and response bodies are not being saved: uploads to the log storage fail (SignatureDoesNotMatch) since 30.10.2026 11:35. Check the bucket credentials.
Stronger security
Role checks on every team, company and uptime change. Sessions that end when a password, role or 2FA setting changes. Rate limits on login and 2FA, uptime checks limited to public addresses, and security headers throughout.
Correct numbers
Endpoint errors are counted within the endpoint, last-hour charts are no longer shifted, weekday labels and size histograms are fixed, and an invalid period returns a clear 400 instead of a 500.
Uptime SLA
The Uptime page now has an SLA summary, and each check shows its current status and how long it has held.
Cleaner settings
Placeholder tabs and fallback values are gone, company info now saves correctly, and Settings show what your role can change.
