All systems operational.

Xpnsr operates three core services — Expense (real-time transaction processing via Astrada API and Visa/Mastercard rails), CBN (AI article generation via DeepSeek, rank tracking via DataForSEO, and webhook publishing to WordPress/Ghost/Strapi), and Tracker (S2S postback processing, bot detection via fingerprinting, and a Rust-based redirect engine handling millions of clicks per day). All services are monitored 24/7 with automated alerting and on-call engineering response.

About Xpnsr System Status

Xpnsr System Status provides real-time and historical uptime information for all three products — Expense, CBN, and Tracker — as well as the underlying infrastructure components including the API Gateway, Webhook Engine, and Database Cluster. The status page is updated automatically every 60 seconds and reflects the current operational state of each service based on automated health checks, synthetic monitoring probes, and real user monitoring (RUM) data collected from the Xpnsr application. The status indicators use a three-colour system: green for Operational, yellow for Degraded Performance, and red for Major Outage. Each service card displays the current status, a brief description of the service capabilities, and the 30-day uptime percentage calculated from minute-by-minute availability data. The 30-day uptime chart below the service cards provides a visual representation of daily availability, with each column representing one day. Green columns indicate days with 100% uptime, yellow columns indicate days with degraded performance (partial outages or elevated latency), and red columns indicate days with a major outage. Hover over any column to see the exact date. The incident log below the uptime chart documents all recent incidents, including the date and time of occurrence, the duration of the incident, a detailed description of what happened and what caused it, and the resolution status. Each incident is tagged as Resolved, Monitoring, or Investigating. For incidents that are currently being investigated, the status page will display real-time updates from the engineering team. The Xpnsr infrastructure runs on a multi-region Kubernetes cluster deployed across eu-central-1 (Frankfurt) and eu-west-1 (Ireland) with automatic failover between regions. The API Gateway handles all incoming requests and routes them to the appropriate microservice — the Expense service for card transaction processing via the Astrada API, the CBN service for keyword rank tracking via DataForSEO and article generation via DeepSeek, and the Tracker service for click and conversion tracking via S2S postback endpoints. Each microservice runs in its own Kubernetes namespace with dedicated resource limits and horizontal pod autoscaling based on CPU and memory utilization. The Webhook Engine is a separate service responsible for delivering outbound webhooks to accounting integrations (QuickBooks, Xero), CMS platforms (WordPress, Ghost, Strapi), and offer networks (MaxBounty, CPA.house, AdCombo, ClickDealer). Webhook delivery is retried up to 5 times with exponential backoff, and failed deliveries are logged for manual review. The Database Cluster consists of PostgreSQL 16 instances with streaming replication across two availability zones. Read replicas are used for dashboard queries and reporting, while the primary instance handles transactional workloads. Automated backups are taken every 6 hours and retained for 30 days. Point-in-time recovery is supported with a recovery window of 7 days. The Redis cluster provides caching for session data, API response caching, and the activity feed event bus. Redis is deployed in cluster mode with three master nodes and three replica nodes, distributed across availability zones. The message queue (RabbitMQ) handles asynchronous task processing including article generation jobs, webhook deliveries, and batch data exports. The monitoring stack consists of Prometheus for metrics collection, Grafana for dashboards, and PagerDuty for alerting. Synthetic monitoring probes run every 60 seconds from three geographic locations — US East, EU Central, and Asia Pacific — and measure API response times, error rates, and end-to-end transaction flows. Real user monitoring (RUM) data is collected via the Xpnsr JavaScript SDK and provides visibility into page load times, API call latencies, and JavaScript errors experienced by actual users. Alert thresholds are configured for key metrics: API p99 latency above 500ms for more than 5 minutes triggers a warning alert, above 1000ms for more than 2 minutes triggers a critical alert. Error rate above 1% for more than 3 minutes triggers a critical alert. Webhook delivery success rate below 99% for more than 5 minutes triggers a warning alert. Database replication lag above 10 seconds for more than 2 minutes triggers a critical alert. All alerts are routed to PagerDuty with on-call rotations for the engineering team. Incident response follows a documented playbook with defined severity levels: SEV1 (Major Outage) requires immediate response with a 15-minute SLA for initial acknowledgment and a 60-minute SLA for mitigation. SEV2 (Degraded Performance) requires a 30-minute acknowledgment SLA and a 4-hour mitigation SLA. SEV3 (Minor Issue) requires a 2-hour acknowledgment SLA and a 24-hour mitigation SLA. After each incident, a post-mortem is conducted within 48 hours and published to the incident log. The post-mortem includes the root cause analysis, the timeline of events, the actions taken to resolve the incident, and the preventive measures implemented to avoid recurrence. For scheduled maintenance, we provide at least 72 hours notice via the status page, email notifications to registered accounts, and the Xpnsr Telegram channel. Maintenance windows are scheduled during off-peak hours (22:00-06:00 UTC) whenever possible. During maintenance, affected services may be unavailable or operate in read-only mode. All maintenance is documented in the incident log with the Scheduled Maintenance tag. If you are experiencing issues that are not reflected on the status page, please contact our support team at support@xpnsr.tech. For urgent issues, use the PagerDuty escalation path available to Enterprise customers. We also provide a public API for status data at status.xpnsr.tech/api/v1/status that returns JSON-formatted availability data for integration with your own monitoring tools. The API supports CORS and returns the current status of all services, the 30-day uptime percentages, and the list of recent incidents. Rate limiting is set at 100 requests per minute per IP address. For Enterprise customers, we offer a dedicated status page with custom branding, private incident reporting, and SLA monitoring dashboards. Contact your account manager or reach out to enterprise@xpnsr.tech for more information about Enterprise status page features. Our infrastructure undergoes regular security audits and penetration testing. We maintain SOC 2 Type II certification and comply with GDPR data protection requirements. All data is encrypted at rest using AES-256 and in transit using TLS 1.3. The status page itself is hosted on a separate infrastructure stack with independent monitoring to ensure availability even during a major outage of the primary platform. The status page is served from a static CDN with a 99.99% uptime SLA and can be accessed even if the main Xpnsr application is unavailable. We also provide an RSS feed of incident updates at status.xpnsr.tech/rss for integration with your preferred feed reader. For real-time notifications, you can subscribe to status updates via email by clicking the Subscribe button at the top of the page, or join the Xpnsr Telegram channel at t.me/xpnsr_status for instant notifications about incidents and maintenance events. Telegram notifications include the incident severity level, affected services, and a link to the status page for detailed information. We recommend subscribing to at least one notification channel to stay informed about service availability. Our commitment is to maintain 99.9% uptime for all services, measured on a monthly basis. If we fail to meet this commitment, affected customers are eligible for service credits as outlined in the Xpnsr Service Level Agreement. The SLA details are available in the Terms of Service and can be provided upon request by contacting support@xpnsr.tech. For the most up-to-date information about planned features, scheduled maintenance, and product updates, please refer to the Xpnsr Changelog at changelog.html and the Xpnsr Blog at blog.html for detailed technical articles and product announcements.