Cronly
Cronly monitors cron jobs, SSL certificates, servers, and crontab backups and reports operational alerts.
Verdict
Common use cases
- Create heartbeat monitors for nightly backup jobs
- Check SSL certificate expiry before renewal
- Audit all active monitors across projects
- Delete stale monitors after decommissioning services
- Organize checks by environment or team
Integration
- Vendor
- Cronly
- Category
- other
- Auth
- API_KEY
- Tools
- 10
- Composio slug
cronly
Tools
- Create Certificate Monitor
Create an SSL/TLS certificate-expiry monitor for a hostname and port.
- Create Monitor
Create a cron-job heartbeat monitor and return its ID and sensitive pulse token.
- Create Project
Create a project for organizing Cronly monitors and certificate checks.
- Delete Certificate Monitordestructive
Permanently delete an SSL/TLS certificate monitor by numeric ID.
- Delete Monitordestructive
Permanently delete a cron-job monitor by numeric ID.
- Delete Projectdestructive
Permanently delete a Cronly project by numeric ID.
- Get Company
Return safe organization, timezone, and subscription-summary fields for the connected Cronly account without exposing billing or integration secrets.
- Get Resource
Get one monitor, project, certificate, user, server, or backup by its resource identity.
- List Resources
List notifications, monitors, projects, certificates, users, servers, or backups. Notifications return one page with a continuation cursor; other resource types return their complete arrays.
- Pulse Monitor
Record a successful heartbeat for a monitor using its sensitive pulse token. This changes monitor run state even though Cronly exposes it as GET.
Setup
Setup guide
- 11. In Switchy, open your workspace settings and navigate to the Integrations tab. 2. Click 'Add MCP Server' and select Cronly from the list. 3. Open your Cronly dashboard, go to Settings → API Keys, and generate a new key with read and write permissions. 4. Paste the API key into Switchy's configuration field and click Connect. 5. Return to any Project in Switchy and type '@Cronly get company' to confirm the connection works — you should see your organization name and timezone. 6. To create a monitor, type '@Cronly create monitor' followed by a name and expected interval, and Cronly will return a pulse URL you can call from your cron job.
What teammates see: by default, memories from Cronly are scoped to the Project (PROJECT visibility) - you can mark any memory PRIVATE or share it ORG-wide.
Works well with
Top models
Compatibility data appears once enough Projects have used this MCP together with a given model.
How Switchy teams use it
Starter prompts
Create Backup Monitor
@Cronly create a monitor named 'Production DB Backup' that expects a heartbeat every 24 hours. Return the pulse URL I need to call from the backup script.
Check Certificate Expiry
@Cronly create a certificate monitor for api.example.com on port 443. Let me know when it's set up and when the cert expires.
Audit Active Monitors
@Cronly get the project named 'Production Services' and show me all monitors inside it, including their last heartbeat times.
Delete Stale Monitor
@Cronly delete the monitor with ID 12345. Confirm it's gone and won't send alerts anymore.
Create Environment Project
@Cronly create a project named 'Staging Environment' and move all monitors with 'staging' in the name into it.
Example outputs
Illustrative - representative of the model's voice and quality, not literal recordings.
@cronly list all certificate monitors that expire in the next 30 days and show me which projects they belong to
Based on the current certificate monitors in your Cronly account, here are the certificates expiring within 30 days: • api.example.com:443 — expires Jan 15, 2025 (12 days) — Project: Production Infrastructure • staging.app.com:8443 — expires Jan 22, 2025 (19 days) — Project: Staging Environment • legacy.service.io:443 — expires Feb 2, 2025 (29 days) — Project: Legacy Systems All three monitors are active and will alert via your configured channels when they reach the 14-day threshold.
This example demonstrates read-heavy retrieval across multiple certificate monitors. The MCP can fetch monitor details and project associations, but the actual expiry dates and alert thresholds depend on your account's current state. Requires API key with read access to both monitors and projects.
@cronly create a new heartbeat monitor called 'Nightly ETL Job' that expects a ping every 6 hours, and put it in the Data Pipeline project
Created heartbeat monitor successfully: **Monitor ID:** 8472 **Name:** Nightly ETL Job **Expected Interval:** Every 6 hours **Project:** Data Pipeline **Pulse URL:** https://cronly.io/pulse/8472/a7f3c9d1e4b2... Your ETL job should POST or GET to this pulse URL at least once every 6 hours. If Cronly doesn't receive a ping within that window, it will trigger an alert through your configured notification channels. Store the pulse token securely — it's sensitive and cannot be retrieved again.
This write example shows monitor creation with project assignment. The MCP returns a sensitive pulse token that your cron job must use to check in. This token is only shown once, so the user must capture it immediately. Requires API key with write permissions on monitors and projects.
@cronly review all monitors that haven't received a heartbeat in the last 24 hours and draft an incident summary for our ops team
Found 3 monitors with missed heartbeats in the past 24 hours: **Incident Summary — January 3, 2025** 1. **Database Backup Job** (ID: 3401) — Last ping: 31 hours ago. Expected every 12 hours. Project: Production Infrastructure. 2. **API Health Check** (ID: 5829) — Last ping: 26 hours ago. Expected every 4 hours. Project: Core Services. 3. **Log Rotation Script** (ID: 6103) — Last ping: 28 hours ago. Expected every 24 hours. Project: Maintenance Tasks. All three monitors are currently in alert state. Recommend immediate investigation of the Database Backup Job given its 12-hour SLA and 31-hour silence. The API Health Check may indicate a service outage requiring escalation.
This synthesis example pairs Cronly's monitor data with AI reasoning to prioritize incidents. The MCP provides raw heartbeat timestamps and intervals; the AI interprets urgency and drafts human-readable summaries. Useful for daily standups or incident triage, but the AI cannot directly resolve alerts or silence monitors.
Use-case deep-dives
When Cronly beats cron-only for small-team reliability
A 3-person SaaS team runs nightly database backups and weekly snapshot jobs. They used to check logs manually every Monday. With Cronly's heartbeat monitors, each cron job pings a unique endpoint when it completes. If the backup misses its window, the team gets a Slack alert before customers notice. The certificate monitors catch expiring SSL certs 30 days out. This works because the team has under 20 scheduled jobs and wants dead-simple alerting without standing up a full observability stack. If you're running more than 50 jobs or need custom retry logic, you'll outgrow this fast. For small teams who just need 'did the thing run,' Cronly closes the loop without adding ops overhead.
Why agencies use Cronly for multi-tenant monitoring
A 6-person dev agency manages 15 client sites. Each client gets a Cronly project with certificate monitors on their domains and heartbeat monitors for their backup scripts. The agency shares read-only project links with clients so they see uptime without touching the agency's main dashboard. This setup works because Cronly's project model maps cleanly to client boundaries and the API key lets the team script monitor creation during site launches. The 10-tool MCP scope is enough to automate the full lifecycle: create project, add monitors, delete when a client churns. If you need sub-5-minute check intervals or complex dependency chains, look elsewhere. For agencies billing monthly retainers and needing proof of proactive monitoring, Cronly delivers the client-facing transparency without per-seat SaaS bloat.
When Cronly's monitor history satisfies SOC2 evidence
A 10-person fintech startup needs SOC2 Type II and must prove their daily reconciliation jobs ran on schedule for the audit period. They use Cronly heartbeat monitors on every compliance-critical cron job. The monitor history becomes the audit artifact: timestamps show the job pulsed every day at 3am, and any missed pulses triggered alerts the team documented in their incident log. The certificate monitors cover their payment gateway endpoints. This works because Cronly's get-resource tool pulls historical pulse data the auditors accept as evidence. If your compliance framework requires immutable logs or needs integration with a SIEM, Cronly won't cut it alone. For startups in their first SOC2 cycle who need lightweight proof their scheduled jobs actually ran, Cronly turns cron into an auditable control.
Frequently asked
What does the Cronly MCP do in Switchy?
It lets your AI agents create and manage uptime monitors for cron jobs and SSL certificates. Agents can set up heartbeat checks, track certificate expiry dates, organize monitors into projects, and pull status reports — all without leaving the conversation. Useful for teams that want monitoring setup automated or triggered by other workflows.
Do I need admin access to connect Cronly?
You need an API key from your Cronly account, which typically requires account-owner or admin permissions to generate. The key grants full read-write access to monitors, projects, and certificate checks. If you're on a team plan, confirm with your Cronly admin before connecting it to Switchy.
Can the MCP send alerts when a monitor fails?
No. The MCP creates and manages monitors but doesn't handle alerting. Cronly sends failure notifications through its own channels — email, Slack, webhooks — configured in your Cronly dashboard. Use this MCP to automate monitor creation; rely on Cronly's native alerting for the actual incident response.
Why use this instead of the Cronly web UI?
The MCP makes sense when you want monitoring setup driven by AI logic or integrated into larger workflows. For example, an agent could spin up a new heartbeat monitor every time it deploys a cron job, or check certificate expiry as part of a security audit. For one-off manual setup, the web UI is faster.
Who on the team should connect this MCP?
Whoever owns your Cronly account and has the API key. Since the MCP can delete monitors and projects, treat it like admin-level access. If multiple people need to create monitors via Switchy, share the workspace but keep the API key in one trusted person's hands.