Hello, everyone in the TRIGGERcmd community!

I'd like to share a project I've started because I really appreciate the work Rus does and makes available to everyone in this community.

I took the initiative and decided to register the domain triggercmdstatus.com to create a public monitoring platform that allows us to track the availability of essential services, APIs used by our automations, and other components that are important to the TRIGGERcmd ecosystem.

The goal is to contribute to the community by providing a centralized view of service availability and helping identify potential issues that could affect our automations, including those triggered through voice assistants.

1. Domain and Infrastructure:

The triggercmdstatus.com domain is managed through Cloudflare, with DNSSEC enabled, adding an extra layer of protection to DNS resolution.

To build the infrastructure, I provisioned three servers distributed across different geographic regions:

• Oracle Cloud — Instance 1: 1 GB RAM and 1 OCPU.
• Oracle Cloud — Instance 2: 1 GB RAM and 1 OCPU.
• KingHost — VPS: 4 GB RAM and 2 vCPUs.
• All instances have been optimized at the Kernel, Swap, CPUs, and RAM Levels.

These three servers form a distributed architecture designed to improve availability and provide geographic redundancy.

The goal is to reduce dependence on a single server or location, making the monitoring infrastructure more resilient to potential failures and regional outages.

2. Project Goals:

This project was created with the following goals in mind:

• Monitor the availability of major global services used by the community.
• Track the APIs that support automations integrated with the TRIGGERcmd.com platform.
• Check DNS resolution services and network connectivity.
• Use distributed probes to collect connectivity metrics from different locations.
• Make it easier to identify potential failures in monitored services.
• Help distinguish external service issues from potential instability in a user's home internet connection.
• Provide a public dashboard that is easy to access without depending on a specific computer.

It's important to note that monitoring helps with troubleshooting, but it cannot independently determine the root cause of every failure. Results should be evaluated alongside local network conditions and the other services involved.

3. Platforms and Technologies:

The infrastructure runs Ubuntu 24.04.5 LTS as its operating system and uses Docker to run services in containers.

3.1. Uptime Kuma — Open-Source Monitoring Platform

Uptime Kuma provides the status dashboard and monitors the configured services.

• Version: 2.5.5
• Official project: https://github.com/louislam/uptime-kuma
• Credits: Louis Lam and the project contributors.

The platform allows users to check monitor statuses, review availability information, and identify potential interruptions affecting monitored services.

3.2. Cloudflare Tunnel — Secure Application Access

Public access to the application is provided through Cloudflare Tunnel, running in a Docker container.

• Platform: Cloudflare One — Zero Trust
• Dashboard: https://dash.cloudflare.com/one
• Credits: Cloudflare, Inc.

Cloudflare Tunnel allows the application to be published without directly exposing inbound server ports to the internet, depending on the configuration in use.

I've also configured Cloudflare features to improve dashboard delivery and availability:

• Two-hour cache: Designed to reduce repeated requests to the origin infrastructure and lower resource consumption.
• Cloudflare CDN: Used to optimize content delivery to visitors in different geographic locations.
• HTTPS with an SSL/TLS certificate: Protects communication between visitors and the public endpoint.

Cache rules are configured with the behavior of the served resources in mind. Dynamic content and monitoring responses must be handled appropriately to prevent outdated information from being displayed as if it were current.

The goal is to balance performance, reduced server load, and the reliability of the information displayed.

3.3. Globalping — Distributed Monitoring

Globalping Probe is also integrated into the infrastructure and runs in a Docker container. It complements the monitoring setup with connectivity metrics collected from different locations.

• Project and platform: https://globalping.io
• Credits: Globalping.io and its contributors.

Using a distributed monitoring probe provides a broader perspective on service availability, helping reveal conditions that might not be noticeable from a single home internet connection.

4. Monitor Organization:

During the initial phase of the project, 12 monitors were configured and organized into four groups to make the dashboard easier to navigate.

Group 1 — Server

This group monitors the infrastructure components.

1. Uptime Kuma - Cluster: Monitors the cluster infrastructure.
2. Cloudflare - Tunnel: Tracks the availability of the tunnel used to access the application.
3. Globalping - Probe: Tracks the availability of the probe used for global monitoring metrics.

Group 2 — API

This group monitors API services used by the ecosystem and its automations.

4. TRIGGERcmd.com API: Monitors the availability of the TRIGGERcmd API.
5. MeuIP.com API: Monitors the availability of the MeuIP.com API.
6. IPinfo.io API: Monitors the availability of the IPinfo.io API.

These monitors help identify outages affecting services accessed by automations and scripts that depend on these APIs.

Group 3 — ICMP

This group checks ICMP connectivity to public DNS servers.

7. Cloudflare - DNS: Checks ICMP connectivity to Cloudflare's DNS service.
8. Google - DNS: Checks ICMP connectivity to Google's public DNS service.

These tests provide information about connectivity to the configured destinations. However, an ICMP response failure does not necessarily mean that the DNS service itself is unavailable, since ICMP traffic may be filtered.

Group 4 — Resolution

This group monitors DNS name resolution.

9. Cloudflare - Resolution: Monitors DNS resolution using Cloudflare.
10. Google - Resolution: Monitors DNS resolution using Google.
11. TRIGGERcmd.com - Cloudflare: Checks resolution of the TRIGGERcmd.com domain through Cloudflare.
12. TRIGGERcmd.com - Google: Checks resolution of the TRIGGERcmd.com domain through Google.

This organization makes it possible to monitor both resolver availability and the ability to resolve the specific TRIGGERcmd.com domain.

Comparing the results can help identify DNS resolution issues that may prevent access to services even when general internet connectivity is available.

5. Public Access and Compatibility

The dashboard is publicly available at:

https://dash.triggercmdstatus.com

The interface is designed for use across different devices, including:

• Desktop and laptop computers.
• Smartphones and tablets.
• Smart TVs with compatible web browsers.
• IoT devices with a compatible browser or another supported way to access the page.

The dashboard is responsive and works with most modern web browsers, adapting its layout to different screen sizes.

The goal is to allow anyone in the community to check service statuses without installing a dedicated application.

6. Why would this monitoring be important?

Anyone who uses TRIGGERcmd with Alexa, other voice assistants, scripts, and automations knows that a failure does not always originate from the computer or device responsible for executing a command.

In some cases, the problem may be related to:

• API outages.
• DNS resolution issues.
• Connectivity failures between networks.
• Instability in third-party services.
• Regional outages or access infrastructure problems.

A centralized dashboard with distributed monitors makes it easier to gather information that can help investigate these situations.

For example, if an automation stops working, checking the dashboard may provide useful clues about the availability of the monitored services at that moment. This does not replace local troubleshooting, but it provides an additional source of information for diagnosing the problem.

7. Final Thoughts:

This project was inspired by my appreciation for TRIGGERcmd and the work that @Russ and all the Developers make available to the community.

The goal is not to replace existing tools, but to contribute a complementary, public, and accessible resource that can be useful to all of us.

The infrastructure was designed with geographic redundancy, service monitoring, DNS resolution checks, and content delivery features to provide a more reliable monitoring experience.

I plan to continue improving the project by adding new monitors and refining the monitoring mechanisms as new needs arise.

Feel free to visit the dashboard:

https://dash.triggercmdstatus.com

I hope this resource proves useful to the community and helps us better understand the availability of the services involved in our automations.

Special thanks to @Russ and all the Developers for developing and maintaining TRIGGERcmd, as well as to all the developers and contributors behind the open-source tools and services used in this project.

Thank you, everyone!

Author: Igor Neth dos Santos
Alma Mater: UniCesumar — Technology Degree in Computer Networks (2015–2018)
Project: TRIGGERcmd - Service Status | https://dash.triggercmdstatus.com

LinkedIn:
https://www.linkedin.com/in/igorneth