Skip to main content
Hayon exposes admin-level analytics and controls that give you a real-time view of platform health, user distribution, and subscription activity. These tools are designed for operators and self-hosted maintainers who need visibility into how the platform is performing.

​
Admin analytics overview

The analytics endpoint aggregates user data across the entire platform and returns a summary of key metrics. 
curl http://localhost:5000/api/admin/analytics \
  -H "Authorization: Bearer <admin-token>"
Response: 
{
  "message": "Analytics retrieved successfully",
  "data": {
    "totalUsers": 142,
    "activeUsers": 130,
    "inactiveUsers": 12,
    "paidUsers": 38,
    "monthlyGrowth": 25.5,
    "topPlan": "Free"
  }
}

​
Metrics explained

Total users

The total number of registered accounts on the platform, regardless of plan or activity status.

Active users

Users with isDisabled: false. These accounts can log in and use the platform normally.

Inactive users

Users with isDisabled: true. These accounts have been deactivated by an admin and cannot log in.

Paid users

Users currently on the Pro plan with an active Stripe subscription.

Monthly growth

Percentage growth in registered users over the past month.

Top plan

The most common subscription plan across all users — either "Free" or "Professional".

​
Monitoring platform health

Beyond the analytics endpoint, a healthy Hayon deployment depends on several background services. Use the following checklist when diagnosing platform issues.
All user data, posts, subscription state, and usage counters are stored in MongoDB. A failed or slow MongoDB connection will cause 500 errors across all API routes. Monitor connection pool health and query latency, especially on findAllUsers queries which scan the entire users collection.
Redis is used for session caching and rate limiting. If Redis goes down, request throttling may stop working, potentially exposing the API to abuse. Check Redis connectivity and memory usage.
Post scheduling in Hayon relies on RabbitMQ queues and background worker processes. If workers stop consuming, scheduled posts will queue up but not publish. Monitor queue depth and consumer count in the RabbitMQ management UI.
Subscription upgrades, renewals, and cancellations are all driven by Stripe webhooks. If the /api/payments/webhook endpoint is unreachable or returning errors, subscription state will fall out of sync. Check the Stripe Dashboard under Developers → Webhooks for failed delivery attempts and replay them if needed.
Post media (images, videos) is stored in AWS S3. Monitor bucket availability and IAM key validity. A failed S3 upload will prevent media-rich posts from being created.
Hayon uses structured logging via a logger utility throughout the backend. Application logs are your primary diagnostic tool. Set the log level to debug in development for full request and event traces.

​
Viewing system-wide post statistics

Post statistics are aggregated at the user level through the usage field on each user document. To understand platform-wide posting activity:
  1. Call GET /api/admin/get-all-users to retrieve all user records.
  2. Aggregate usage.postsCreated and usage.captionGenerations across all users.
  3. Compare against limits.maxPosts and limits.maxCaptionGenerations to identify users approaching their limits.
Users who have reached their limits appear in the platform in a degraded state — they can log in and view content but cannot create new posts or generate captions until their plan is upgraded or the next billing cycle begins.
If a user reports they cannot create posts despite having an active Pro subscription, check whether their usage.postsCreated has reached limits.maxPosts. An admin can reset this by updating the user’s plan to free and back to pro via PATCH /api/admin/update-user-plan/:id, or by directly modifying the usage counter in MongoDB.

​
Managing platform connections across users

Social platform connections (Bluesky, Tumblr, Facebook, Threads, Mastodon) are stored per user. As an admin, you can investigate connection issues by:
  • Retrieving the user’s full document via GET /api/admin/get-all-users and inspecting their platform credentials.
  • Deactivating accounts that are abusing platform integrations using PATCH /api/admin/update-user-activity/:id.
  • Revoking Pro access for accounts suspected of exceeding fair-use thresholds using PATCH /api/admin/update-user-plan/:id.
Platform OAuth tokens are stored per user and are not visible to other users. Admins can see account metadata but platform credentials are encrypted at rest.

​
Rate limiting configuration

Hayon enforces two categories of rate limits:

Plan-based usage limits

Enforced at the middleware layer via checkUserPostLimit and checkUserGenerationLimit. These limits are stored on the user document and checked on every relevant API call.

Network-level rate limiting

Configured via Redis-backed middleware on the Express server. This protects against API abuse and DDoS patterns by limiting the number of requests per IP or token within a time window.
To adjust plan-based limits platform-wide, update the PLAN_LIMITS configuration in src/config/plans.ts: 
export const PLAN_LIMITS = {
  free: {
    maxPosts: 30,
    maxCaptionGenerations: 15,
  },
  pro: {
    maxPosts: 60,
    maxCaptionGenerations: 30,
  },
};
Changing PLAN_LIMITS only applies to newly created accounts or accounts whose plan is explicitly updated. Existing users retain their previously set limits values in MongoDB. To apply new limits to all users, you must run a migration to update every user document.

​
Background worker monitoring

Hayon uses RabbitMQ-backed background workers to process scheduled posts. Key things to monitor:
1

Check queue depth

In the RabbitMQ management UI, navigate to Queues and verify that your scheduled post queue is being consumed. A growing queue with no consumers indicates workers are down.
2

Inspect failed messages

Dead-lettered messages in the DLQ (Dead Letter Queue) represent posts that failed to publish after retry attempts. Review these regularly and cross-reference with application logs to identify recurring platform API failures.
3

Restart workers if needed

Workers are independent Node.js processes. If a worker crashes, restart it using your process manager (PM2, systemd, or Docker). Workers automatically reconnect to RabbitMQ on startup.
4

Verify Stripe webhook processor

The webhook endpoint at POST /api/payments/webhook is synchronous — it processes events in-band on the main Express process. If response times are slow, Stripe may retry delivery. Ensure the endpoint responds within Stripe’s 30-second timeout.

Build docs developers (and LLMs) love

Get started for freeTalk to us