Separate ingestion path
Telemetry enters through cron.life, separate from app, API, marketing, and documentation hostnames. The ingestion and management APIs remain separate processes.
Security and reliability
The controls, evidence, and limits behind CronRadar.
This is the customer-facing source for how the working service handles data and reliability. It does not claim certifications, redundant regions, guaranteed response times, or a contractual service level.
- API keys stored as hashes
- HTTPS public endpoints
- 30-day run history
Architecture
Separated services, with the single-region limit stated.
Cloudflare Tunnel and Traefik route traffic to separate ingestion, management API, authenticated application, marketing, and documentation services. PostgreSQL stores customer configuration and evidence; Hangfire workers evaluate schedules and dispatch alerts.
Shared persistence
One PostgreSQL service stores configuration, telemetry, incident, delivery, and queue evidence. CronRadar does not claim multi-region or multi-replica failover.
Independent operations signal
The overdue detector reports to an external dead-man endpoint, and background-job failures use a separate external notification path. CronRadar self-monitoring is supplementary.
Data boundary
Execution evidence, not production contents.
CronRadar needs enough bounded evidence to identify an automation, evaluate its expected run, explain an incident, and deliver an alert.
Collected
- Account email, display name, and the identity-provider identifier when OAuth is used.
- Team, application, automation, schedule, ownership, alert destination, and collaborator settings.
- Lifecycle event, timestamp, source, opaque run identifier, retry number, and derived duration or health state.
- Optional failure context and up to five configured numeric or boolean outcome values per run.
- Billing status, support messages, security request metadata, and bounded first-party funnel milestones.
Deliberately not collected
- Application logs, distributed traces, or metrics streams.
- Job arguments, arbitrary payloads, customer database records, or source repository contents.
- The content behind a customer-provided runbook, repository, or log-search link.
- Payment card numbers, which are entered into and processed by Stripe.
- Session recordings, keystrokes, cursor movement, full analytics URLs, IP addresses, or user agents for product analytics.
Do not put secrets, personal data, records, or full logs in monitor keys, failure messages, outcome keys, or alert configuration.
Encryption and secrets
Precise controls instead of a blanket encryption claim.
Application API keys
Generated from 32 cryptographically random bytes and stored as SHA-256 hashes. The raw key is returned at creation or rotation and is not available for later display.
Authentication secrets
Magic-link tokens are stored as hashes. Slack OAuth bot tokens are protected with ASP.NET Core Data Protection. Authentication cookies use persisted Data Protection keys.
Transport and configuration
Production public endpoints use HTTPS. Deployment credentials come from environment configuration. Customer webhook URLs and PagerDuty keys are stored as service configuration; CronRadar does not claim all database fields are application-encrypted.
Retention
Bounded operational history.
The daily retention worker applies these windows to the evidence used by the product. Account and configuration records remain while the account is active.
30 days
Run evidence
Pings, lifecycle events, correlated runs, and outcome evaluations.
90 days
Incident evidence
Alerts and their per-channel delivery attempts.
Support-managed
Account deletion
Deletion requests currently go through support. No deletion-completion deadline is promised; legal, fraud-prevention, and payment records may need to remain.
External services
Who can process data, and when.
Some services are part of operating CronRadar; others receive data only when you choose that sign-in, billing, or alert path. Provider policies can change, so the links go to their current primary documentation.
| Service | Why it is used | Data boundary |
|---|---|---|
| Cloudflare | TLS termination, tunnel ingress, proxying, and edge protection for every public service. | Public web and API traffic, including IP address and request metadata. |
| Stripe | Subscription billing when a customer chooses a paid plan. | Billing identity, subscription state, and payment information provided directly to Stripe. CronRadar does not store card numbers. |
| GitHub, Google, or Microsoft | Interactive sign-in only when that provider is selected. | Provider identifier, name, and email needed to create or find the CronRadar account. CronRadar does not request repository contents. |
| SMTP or Mailgun | Magic links, account messages, reliability summaries, and email alerts. | Recipient address and the content of the requested account message or alert. |
| Customer alert destinations | Slack, Discord, PagerDuty, or an HTTPS webhook, only when a customer enables it. | Bounded incident context and the configured destination needed to deliver the alert. |
Recovery
Backups and incidents, with proof limits.
Backup tooling
The deploy workflow creates a PostgreSQL custom-format backup, validates its archive listing, records a SHA-256 checksum, and can copy it to an encrypted off-host target before replacing services.
Restore practice
An isolated restore command restores into a disposable PostgreSQL 16 instance and checks a core table. The repository does not prove that production off-host copies or quarterly drills have occurred.
Incident practice
Operators preserve evidence, recover dependencies in documented order, verify ingestion, detection and delivery, and record impact and follow-up. No recovery-time or recovery-point objective is promised.
Availability and status history
Only publish a number when there is a complete measurement.
A target is not measured availability. CronRadar has not yet published a complete independent availability series with a defined source and window, so there is no percentage to report today.
Not published
Measured availability
No percentage is shown until a complete measurement source and reporting window can be named.
Not established
History coverage start
No verified historical incident register is available for publication yet. This does not mean there were zero incidents.
No SLA
Contractual commitment
There are no service credits, guaranteed alert times, or guaranteed support response times.
Status history
There are no verified entries available for publication. When reporting begins, this section will identify the coverage start and list customer-impacting incidents with dates, affected service, impact, resolution, and a factual follow-up. Absence of an entry before that date will never be described as incident-free operation.
Customer and sales answers
One answer for the questions that matter.
Does CronRadar have a compliance certification?
No certification is claimed. SSO, SAML, audit logs, and compliance attestations are outside the current product boundary.
Is the service redundant across regions?
No. The documented production design is a single-region, single-instance stack with no multi-region failover or multi-replica availability claim.
Is all stored data encrypted?
No blanket claim is made. API and magic-link secrets are hashed, Slack OAuth bot tokens are protected, and public traffic uses HTTPS. Customer-configured alert destinations are stored as service configuration.
Do you offer an SLA or guaranteed response time?
No. Service operation, alert delivery, and support are best effort, without service credits or guaranteed timing.
How do I report a security or reliability concern?
Email [email protected] or use the contact form. Include timestamps and affected service or automation, but never include API keys, tokens, payloads, or customer records.
Can CronRadar be the only monitor of a critical system?
No monitoring service should be its own sole dead-man check. Keep an independent operational path for critical systems and test the configured alert route.
Need the underlying policy or help?
Read the Privacy Policy and Terms of Service, or send a secret-free report to [email protected].
Review the boundary, then test the workflow.
Start without a card and verify a real success and safe failure before depending on CronRadar for production coverage.