Stop paying
for cloud you
aren't using.

Most teams are up and running in under 30 minutes. Connect your cloud accounts using the guided onboarding flow, browse your inventory, set a schedule, and you're done. No agents to install, no code to write.

Today PYC supports: EC2 and RDS on AWS, Virtual Machines and Azure SQL on Azure, Compute Engine and Cloud SQL on GCP. Coming soon: ECS, EKS (AWS), AKS (Azure), GKE (GCP). If you need a resource type that's not listed, reach out - we're actively expanding.

No. Parking is a clean stop - not a terminate. Compute pauses, but your data stays exactly where it is. On EC2, the ENI stays attached, EBS volumes persist, and the instance is recoverable in full. On RDS, your database storage and snapshots are untouched. When PYC starts the resource again, it comes back exactly as you left it.

PYC starts your resource at exactly the time you specify. If your resource takes longer to boot - for example, RDS instances can take a few minutes to become available - factor that in when setting your start time. If your team starts at 9am, you might set RDS to start at 8:50am so it's ready when they need it.

Yes - that's one of PYC's core strengths. Pick EC2 instances, Azure VMs, and GCE instances together in a single schedule. One start time, one stop time, all three clouds. No switching between dashboards.

Schedules are anchored to the timezone you configure - not your browser's local time. PYC handles DST automatically, so your 8am schedule fires at 8am year-round regardless of where your team or your servers are located.

Never. PYC uses native cloud identity - cross-account IAM roles for AWS, Managed Identities for Azure, Service Accounts for GCP. We never see, store, or transmit your credentials. Your cloud account is accessed only through the role you create - and you control that role. Revoke it anytime and PYC loses access immediately.

Read-only to discover your resources, and start/stop to act on them. That's it. No IAM changes, no networking permissions, no ability to delete or modify anything. On AWS we use a cross-account IAM role with a specific external ID. On Azure, a Managed Identity. On GCP, a Service Account. All scoped to the minimum possible.

PYC is built primarily for non-production environments - dev, staging, QA, and UAT - where the cost of an unexpected delay in resource availability is low. You can technically connect production accounts and PYC will work the same way, but we don't recommend it as a primary use case. Scheduled start/stop actions depend on cloud APIs, network conditions, and token availability, and any of those can introduce latency or failure. PYC does not accept responsibility for business losses, missed SLAs, or downtime resulting from scheduling failures on production resources. If you do use PYC in production, ensure you have independent monitoring and manual recovery procedures in place.

No - and this is one of the main reasons teams adopt PYC. Developers, PMs, and team leads can start, stop, and schedule their own environments entirely through the PYC dashboard. No AWS console, no Azure portal, no GCP console access needed. Your IAM stays tight. Your security posture stays clean.

Yes. PYC's RBAC lets you assign team-level access so each team sees and schedules only their own resources. One team can't accidentally touch another team's databases. An admin controls what each user can see and do.

Tokens are PYC's unit of usage. Each stop or start action on a resource costs 1 token. Resource Discovery scans are free. You buy tokens upfront - minimum USD200 - and they're deducted as PYC executes start/stop actions on your resources. Top up manually anytime and you're never interrupted. No monthly commitment, no expiry.

Token plan is fully self-serve - buy tokens, use them, top up when needed. No commitment, no contract. Enterprise is for teams that need volume pricing, a dedicated cloud architect, priority support with SLAs, and a custom annual plan. If you're running large environments across multiple accounts, enterprise will work out cheaper.

Your token balance is always visible on the PYC dashboard. As your balance runs low, we send you an email notification so you can top up before it becomes a problem. If your balance hits zero, scheduled actions stop executing - no start or stop will happen until you add more tokens. Top up anytime and your schedules resume immediately.

For the Pay as you go plan, payments are processed through Stripe. You can use any major card or other payment methods supported by Stripe in your region. Our pricing is in USD, but Stripe lets you pay in your local currency. For Enterprise plans, we support bank transfer and invoice-based payment.

Raise a support ticket directly from the PYC portal. You can attach screenshots explaining the problem, and our team typically responds within a few hours.

PYC retries automatically and logs the failure with full detail - resource ID, cloud, account, error reason, and timestamp. You get notified. Every execution is visible in your dashboard at the resource level so nothing is a black box.

Yes. Every stop and start action executed by PYC is logged with timestamp, resource, account, and status. You can see exactly what ran, when, and whether it succeeded - down to the individual resource.