MonitoringWordPress operationsTelegramTypeScript

Know what is happening across your sites without living in dashboards

This five-property WordPress monitoring suite puts the facts needed for a decision in one place. The host API supplies detail in the dashboard, while Telegram provides an on-demand answer when you need it quickly.

It is deliberately a chat-driven checking tool today, not an invented alerting platform. That gives the team a reliable first layer before deciding what should truly interrupt someone.

See how it works Discuss a project like this

At a glance

A practical way to check the portfolio

The job is simple: make the current operational picture easier to find and safer to trust.

Portfolio scope

5 WordPress properties

One site registry keeps every check pointed at the right property.

Two ways to check

Dashboard + Telegram

Use the web view for detail and chat for a quick answer away from your desk.

Hosting connection

Rocket.net API

Hosting facts are converted into consistent, readable site information.

Quick health check

5-second default

Each request returns a status, response time, or useful error message.

The problem

Site operations get fragmented fast

Hosting status, software updates, backups, and visitor activity do not naturally arrive in one place. When someone is away from a desk, even a quick question can mean too many tabs and logins.

The approach

Use each surface for the work it does best

The dashboard holds the deeper picture. Telegram handles the short, on-demand questions that matter in the middle of a busy day.

What you can check

The facts are organized around the site in front of you

You do not have to remember which provider screen owns which part of the answer.

Hosting and site inventory

Confirm which sites and domains are present, along with WordPress and PHP versions and storage information.

Software changes

See plugins and themes, their versions, active state, and available updates without treating every technical detail as a separate login.

Backups and certificates

Review automatic and manual backup records plus complete, in-progress, or failed states alongside certificate information.

Traffic and edge activity

Bring recent requests, content delivery, bandwidth, and security-event context into the same site conversation.

On-demand audience and health checks

Ask the bot whether a site responds, what is happening now, how traffic compares, and which pages lead.

How the hosting connection stays usefulshow

The host API integration normalizes site, domain, plugin, theme, backup, SSL-state, storage, and reporting data into a consistent application model. Sensitive delivery fields are masked before a browser receives them.

Authentication is cached at module scope until shortly before it expires. After an authorization failure, the client clears the cached session, signs in again, and retries the original provider request once; a second failure is returned rather than retried indefinitely.

Plugin and theme calls retain active state, versions, and available updates. The plugin view intentionally filters drop-in plugins, and the backup view keeps manual and automatic records plus complete, in-progress, and failed states.

How it works

From a question to a clear answer

Each step makes it clear what starts the work, what you receive, and what happens when a dependency is not available.

Ask once for the hosting facts you need

Starts when: You open a portfolio, site, or supporting view in the dashboard.
What happens: The system signs in to the host when needed, then gathers the facts for the property you selected.
You get: You see a consistent view of the site, its domain, its software, backup position, certificate position, storage, and recent activity.
If it cannot: If one piece is unavailable, the rest of the view can still give you useful context.

Turn separate reports into one usable picture

Starts when: You choose a reporting period for a site.
What happens: The dashboard asks for traffic, content-delivery, bandwidth, and security-event information separately, then combines the answers it received.
You get: You can inspect the signals that arrived instead of losing the whole screen to one weak data source.
If it cannot: A missing measure is safely shown as unavailable or zero while the other measures remain visible.

Get an answer from chat when you are away from the dashboard

Starts when: You choose a site in Telegram or type one of the available commands.
What happens: The bot checks the selected property and returns a compact answer for reachability, current audience activity, traffic, or top pages.
You get: Routine questions can be answered from a phone without finding the right browser tab first.
If it cannot: A problem with one site is shown in that site result; a full sign-in problem gets a clear operator-facing message.

Refresh the answer without filling chat with copies

Starts when: You tap a Telegram refresh button.
What happens: The bot updates the answer already in the conversation when it can, rather than posting the same answer again.
You get: The chat stays compact enough to scan during an operational check.
If it cannot: If Telegram cannot update the old message, the bot sends one new answer and closes the waiting indicator.

What this means in practice

Instead of deciding whether a site is healthy from scattered clues, your team gets a focused answer with the surrounding context needed to act. A weak upstream service does not erase the information that did arrive.

How partial reporting stays visibleshow

The reporting route uses Promise.allSettled for total requests, CDN requests, bandwidth, and WAF events. Each result can complete or fail independently, so one failing metric stream does not break the view.

Failed streams resolve to safe zero-value fallbacks while successful streams remain chartable. When available, the WAF result also respects a larger total reported by the provider.

Telegram command surface

Seven commands for the questions people actually ask

The bot keeps typed commands and button choices on one path, so the mobile experience does not become a second, fragile implementation.

Find your way around

/help/sites/up

See the command list, the registered sites, or whether the bot itself is available.

See what visitors are doing

/realtime [site]/traffic [site]/top [site]

Check active visitors and pages, compare sessions with a seven-day baseline, or see the leading pages for a selected site.

Check whether a site answers

/status [site]

Check one site or the whole registry and receive its response status, timing, and failure reason when available.

What the bot does on each requestshow

The implemented commands are /help, /sites, /up, /realtime, /status, /traffic, and /top. Typed commands and callback data are normalized into one command context before dispatch.

HTTP health probes follow redirects, use a five-second default timeout, and return structured latency, status, and error data instead of throwing. Analytics commands add active users, top pages, traffic against a rolling seven-day baseline, and top content across the same five-site registry.

How the pieces fit together

Technology chosen for clear operational jobs

The technical choices exist to make the everyday experience more reliable, not to collect logos.

Operator experience

Next.js dashboard, server routes, SWR, Recharts, Telegram Bot API

One surface supports deeper review; the other supports a fast operational question.

Hosting connection

Rocket.net API, typed normalizers, cached provider authentication

Provider-specific responses become stable application information before they reach a screen.

Site and audience signals

HTTP probes, GA4 Data API, static multi-site registry

Every interface uses the same short site identifiers and selection logic.

Runtime and quality

TypeScript, Vercel functions, Vitest, ESLint

Small, testable modules keep command handling, formatting, health checks, and webhook behavior maintainable.

Why two interfaces are better than one

Your team gets a detailed place to investigate and a quick place to ask. Neither one has to pretend to solve every monitoring moment.

Safeguards

Useful answers need deliberate failure behavior

The implementation protects the current phase and states plainly what is intentionally not built yet.

A limited retry, not endless guessing

The host connection gets one clean second attempt after an authorization problem. It does not keep retrying until the user is left waiting.

One missing number does not hide the others

Reporting sources settle independently, so a weak security or delivery report does not make a site look completely unknown.

Only authorized chat requests are accepted

The bot verifies a secret header and operator allowlist, and it handles typed commands and button presses through the same path.

Chat stays readable during refreshes

An unchanged answer counts as success. Old messages that cannot be edited get one fresh reply instead of a trail of duplicates.

The alerting boundary is honest

Today this is an on-demand, chat-driven checking tool. Proactive alerts are a planned next layer, not a feature claimed by the committed bot.

The important operational promise

The system does not pretend that every dependency will always answer. It makes the failure understandable, protects the good information, and avoids claiming an alerting capability that is not present.

How chat refresh and access controls workshow

The Telegram webhook checks its secret header and operator allowlist, removes a bot suffix from typed commands, and treats button callbacks like typed input. Responses use MarkdownV2 formatting with site pickers and refresh controls.

On refresh, the bot edits the existing answer first. An unchanged message is treated as success; an old or deleted message receives one new reply. The callback spinner is answered even when a non-critical edit path has a problem.

What it replaced

Less searching, more informed checks

Before

Hosting facts, backup position, software changes, and audience signals are split across provider screens.

With this approach

The available operations information is organized around the one site you are investigating.

Before

A quick health question means opening a browser and locating the right property.

With this approach

A Telegram command or site button asks for the same property by its short identifier.

Before

Refreshing chat results can create a hard-to-read stream of repeated updates.

With this approach

The existing result is updated when possible, with a single fallback reply when it is not.

Before

One unavailable report can make a monitoring page appear completely broken.

With this approach

Successful report streams remain useful even when another upstream source is unavailable.

What this means for your business

A monitoring pattern people will actually use

Give a managed WordPress portfolio one dependable operations view across several properties.
Answer routine availability and audience questions from a phone while an owner is away from a desk.
Start with useful on-demand checks, then introduce proactive alerts only after the team agrees on thresholds and ownership.
Share operational context without sharing raw hosting credentials with everyone who needs an answer.

Plain-language glossary

Every technical term used on this page, explained without jargon.

API: A controlled way for two software systems to request and exchange information.
Cached authentication: A temporary sign-in session reused so the host is not asked to log in every time.
CDN: A network that delivers site files from locations closer to visitors.
GA4: Google Analytics 4, a system for measuring site visitors and their activity.
HTTP probe: A quick request that checks whether a web address responds and how long it takes.
Promise.allSettled: A JavaScript pattern that collects every result, including failures, without stopping early.
WAF: A web application firewall that records or blocks suspicious web requests.
Webhook: A secure endpoint that receives an event from another service, such as Telegram.

Need clearer site operations?

Build the right check first, then the right alerting layer.

Start with the questions your team asks today. We can map the information, interfaces, safeguards, and future escalation rules that make those answers dependable.

Discuss a project like this