Questions, answered in plain English: AWS monitoring, security & pricing

No, that is the whole point. If you can paste a URL — and, for the AWS features, either click through one read-only role setup or paste a read-only key — you are set. We do the reading and translate everything into plain English, including the one thing to do when something is wrong.

Uptime and latency monitoring works on the Free plan with nothing connected: sign up, paste your site’s URL, and we start checking it. Spend tracking needs an AWS account on Starter and up; the security scan needs one on Starter and up, and cost-waste detection needs one on Pro and up. If your app runs on Vercel, Cloudflare, Render or another host, every part of the product except those AWS features still works for you, and you can connect an AWS account later at any time if you start using AWS.

With an email address and a password on the signup page. Every account starts on the Free plan (no card needed) and you can add your first monitor right away.

Sign in, open the dashboard, and in the Add a monitor panel give it a name, paste your app’s URL, pick a check interval, and save. It is checked the moment you save, then on your plan’s schedule. You can rename it, change its check interval, edit its description, or delete it from the dashboard. Changing the URL means deleting the monitor and adding it again (the history goes with it). Deleting stops its checks immediately.

On the schedule your plan allows: Free hourly, Starter every 15 minutes, and Pro and Scale every 5 minutes. There is also a Check now button on each monitor if you want a fresh result on demand.

Only for the AWS features: your month-to-date spend and budget alerts (Starter and up), the opt-in security scan (Starter and up), and the opt-in cost-waste detection (Pro and up). If all you want is uptime monitoring, you never have to connect AWS at all.

They show you the total. Cost Explorer tells you your account spent $312 this month; Budgets emails you when a number crosses a line. Neither one tells you which resource is doing it or what to do about it. That’s the part we do: a cost-waste finding names the one resource (say, an unused NAT gateway), its estimated monthly cost (about $32/mo), and the one fix, then you decide. Cost Explorer shows you the bill; NimbusWatch tells you the one thing to delete to shrink it.

A pasted spend-tracking key is created with exactly one permission, ce:GetCostAndUsage (“read my costs”). The security scan and cost-waste detection each need their own broader read-only policy, and both are opt-in: nothing runs until you consent. There is no code path that starts, stops, deletes or modifies anything in your account. Every action in those policies grants only reads your account, with one exception: iam:GenerateCredentialReport, which AWS labels a Write action but which only asks IAM to compile a report about your account and changes nothing.

It is the AWS Cost Explorer permission for reading your cost totals. With just that, we can show your month-to-date spend and compare it to your budget, and nothing else. It cannot see your servers, databases, files, or your data.

Two ways, both read-only. Recommended: a 1-click read-only role. Enter your 12-digit AWS account ID, open the pre-filled link to deploy one read-only IAM role in your account with CloudFormation, tick the box CloudFormation shows you acknowledging that it is creating an IAM role with a fixed name, then come back and verify. There is no access key to create or rotate, and you cut us off by deleting the one stack. Advanced: a pasted key. Create an IAM user with no console sign-in, attach the one-permission policy (the JSON is right there to copy), create an access key, and paste the Access key ID and Secret access key. We read your spend right away. Which plans can connect AWS, and how many accounts, is in the table below.

The role bundles exactly the three read-only scopes NimbusWatch offers: spend tracking, the security scan, and cost-waste detection, as one policy of read-only Get / List / Describe actions, plus one action that asks IAM to compile its own credential report and changes nothing (iam:GenerateCredentialReport — the action AWS includes in its own read-only IAMReadOnlyAccess policy), and an explicit deny on write and delete actions. It cannot read the objects inside your S3 buckets, cannot assume other roles, and never changes anything in your account. It can only be assumed by NimbusWatch using an external ID generated just for your account, so no one else can point your role at us.

With the recommended role there is no key to store or rotate at all; you cut us off by deleting the one CloudFormation stack. With a pasted key, it is encrypted at rest and never shown in full again. Either way you stay in control: disconnect the account in your dashboard, or delete the stack (role) or the IAM user/key (key) in AWS. The moment you do, we can no longer read anything.

Recurring money quietly draining out of your bill every month: unused NAT gateways, EC2 instances that bill 24/7 while nothing uses them, unattached elastic IPs, orphaned EBS volumes and snapshots nothing references, disks still attached but idle (near-zero activity over 14 days), EC2 and database instances sized far bigger than their traffic needs, over-provisioned Lambda and DynamoDB resources, and log groups that keep your AWS logs forever. Most findings include an estimated monthly savings figure and the one thing to do, like “delete this unattached disk and save about $12 a month.”

No, they are estimates, clearly flagged as such. AWS pricing varies by region, usage and time, so treat each figure as “about $X a month”, a way to prioritize, not an invoice. Some checks are advisory: a log group kept forever is flagged as awareness even when AWS does not report how much data it holds, in which case there is no figure at all rather than a made-up one.

No, there is no single correct answer. How long to keep logs depends on how long you actually need them for debugging and whether you are required to keep them for compliance. We only flag groups that never expire (or keep logs a very long time) as a nudge to decide; we never insist a particular number, and never change the setting for you. If you must keep logs long-term, export them to S3 instead.

Yes, the same opt-in model: a separate consent step once per account, then read-only runs whenever you like. Fix the findings that matter and re-run the scan to watch the list shrink. The plans differ, though — this scan is Pro and up, while the security scan starts lower, on Starter.

A Starter and up feature that checks your AWS account for fourteen common misconfigurations and tells you, in plain English, what is wrong and the one thing to do about it. It is opt-in and read-only: nothing runs until you enable it, once per account.

• Public storage buckets: S3 buckets anyone on the internet can read or download from.
• Firewall rules open to the entire internet: security groups allowing traffic from 0.0.0.0/0.
• Logins without a second factor: IAM users that have no MFA enabled.
• Root access keys: access keys on your AWS root account, which should never exist.
• Unencrypted disks: EBS volumes stored without encryption at rest.
• Root login without a second factor: your root account can be signed into with a password alone.
• Buckets with no default encryption of your own: new objects are encrypted with an AWS-managed key, not one you choose and can audit.
• Buckets that do not keep old versions: no versioning, so an overwrite or a delete cannot be undone.
• Public access block switched off account-wide: the master switch that stops any bucket going public is not on.
• Threat detection off: GuardDuty is not watching your account for malicious activity.
• Public databases: databases flagged publicly accessible (AWS would give them a public address).
• No working audit trail: CloudTrail is not logging who did what in your account.
• Servers on the old metadata mode: EC2 instances still allowing IMDSv1 instead of the hardened v2.
• Access keys nobody has used in months: stale IAM credentials left lying around.

No, it reports. Each finding comes with a The fix box: the one thing to do, in plain English. The fixing is yours, and we make it obvious.

On the AWS page, open the Security scan section, read the “what you are allowing” list, click the consent button (you do this once per account), then Run the first scan. It reads your storage settings, firewall rules, logins, key ages, databases, audit trail and threat detection. Re-run it any time you change AWS settings.

On Starter yes; on Free no. The security scan is Starter and up, so it is included in Starter, Pro and Scale. Cost-waste detection is the separate, higher one, at Pro and up. On Free the AWS page shows a card for each scan naming the plan that unlocks it. See the plans.

Both scans live in the lower half of your AWS page, in the Security scan section and the Wasted-spend detection section. Nothing runs until you accept their read-only policy, once per account, and that accept button is the last thing in each section: it sits under the list of checks, the “what you are allowing” list and the policy text. Keep scrolling to the bottom of the section and you will reach it. Here is every reason a scan can show nothing, and the one thing to do about each.

1. You have not accepted the policy yet. Until you do, the scan does not run at all and the badge next to the account name reads “Not on yet”. Scroll to the bottom of the Security scan section and click the blue button that reads “I understand, enable the security scan for [your account]”. Then do the same at the bottom of the Wasted-spend detection section, where the button reads “I understand, enable the cost-waste scan for [your account]”. It is once per account: accepting for one account does not turn the scan on for another.
2. The policy changed since you accepted it. If the badge next to the account name reads “Policy changed”, the scan is not looking again until you accept the current policy. Do these two things in this order. First, update the read-only role in your own AWS account: sign in to that AWS account, open CloudFormation, choose the stack you created from our template (its name is nimbuswatch-readonly unless you changed it), then Update, then Replace current template, then Amazon S3 URL, then paste https://nimbuswatch-cloudformation.s3.us-west-2.amazonaws.com/nimbuswatch-readonly-role.yaml and let it finish. Then come back and click “Review and accept the updated policy”. Accepting on our site cannot add a permission to your AWS account; only that stack update does.
3. Your read-only role is behind the current version. This is the one that looks like nothing happening. A check that cannot run because your role in your own AWS account does not have its permission yet is shown as “Not run yet”, with the reason next to it, and never as “nothing found”. If that is what you see, the role needs the update described just above. If you connected with a pasted read-only key instead of the role, the same fix happens in IAM: open Users, choose the nimbuswatch-readonly user you created, and attach the current policy that the AWS page shows in its box. Then run the scan again.
4. No AWS account is connected yet. Each scan reads one AWS account at a time, through that account’s own read-only connection, so there is nothing to scan until one is connected. If the section says “Connect an AWS account to scan it”, connect one on the same page first, with the 1-click read-only role (recommended) or a pasted read-only key, then come back and accept the policy. Connecting is Starter and up; the security scan is Starter and up too, and cost-waste detection is the one that needs Pro and up.
5. Your plan does not include one of the scans. The security scan is Starter and up and cost-waste detection is Pro and up, so each one is missing on a different plan. Where a scan is not included there is no section for it: the AWS page shows a card for that half naming the plan that unlocks it (the security card points at Starter, the cost-waste card at Pro), and on your dashboard the same card is grey and marked with that plan. Nothing is broken. That scan is simply not part of the plan you are on.
6. You accepted it, but the first run has not landed yet. Your dashboard card says “First security scan still on its way”, and the cost-waste card reads the same way. Once accepted, each connected account is scanned about once a day. If you do not want to wait, click “Run the first scan” on the AWS page. A run you start yourself counts as that account's scan, so the next scheduled pass can find nothing due. A run changes nothing in your account.
7. The run did not go through. The AWS page shows a red box headed “The security scan could not run” (or “The cost-waste scan could not run”) with the reason underneath, and the dashboard card says “Scan could not run” rather than pretending one is on its way. The usual reason is that your AWS account does not allow one of the calls yet, and the box names the user or role to attach the exact policy to, printed just below it. Attach that policy in AWS, then click “Run scan again”.
8. The run finished only some of the checks. A run that did not finish every check is never reported as clean, on purpose: a check that did not run is not a check that found nothing. The AWS page lists what did not finish under “Some checks could not finish”, and we try those again on the next scan. Click “Run scan again”. If the reason mentions a permission, do the role update in point 2 first.
9. The last run is too old to say anything about now. Both scans are due about once a day, so a run older than two days means recent scheduled passes have not completed for that account. The page says so, and it will not call the result clean, because nothing has looked recently enough. Click “Run scan again” for a fresh answer.
10. Nothing was found, and that is the real answer. A green “No issues found” box (security) or “Nothing is wasting money” box (cost-waste) means every check ran and found nothing this time. Advisory findings are different: a finding with no dollar figure next to it is still something to look at, and the page will say so rather than call the account clean. Treat any of it as a snapshot, not a guarantee: it is not proof that your AWS account is safe, and a new resource or a changed setting can be found on the next run. Re-run the scan whenever you change something in AWS.

If your situation is not on this list, email support@nimbuswatch.com with the email address on your account, which scan it is, and what the badge next to the account name says. We read every message.

Swipe the table sideways to see every column.

The security scan is included from Starter up, in Starter, Pro and Scale. Cost-waste detection, the scan that puts a dollar figure on what you spend, is included in Pro and Scale only. See the pricing table for the full list of what each plan includes.

The pricing table knows what your account is on. The plan you are already paying for is shown as your current plan and is not a button; a higher plan reads Upgrade and moves the subscription you have; the Free row reads Downgrade and stops the plan at the end of the current billing period, with no part-month refund. If you are on no plan, the button takes you straight to Stripe’s secure payment page. New visitors sign up first: we remember the plan you picked and put one Finish subscribing button on your dashboard, which opens the same Stripe page. You pay monthly in advance, the plan renews automatically until you cancel, and we never see or store your full card number.

Yes. Your plan caps how many monitors and AWS accounts you can have, and the product enforces it: for example, Free allows 1 monitor and no AWS accounts, so saving a second monitor or a first AWS connection on Free will point you to upgrade.

You cancel it yourself: use the Cancel subscription control on your settings page. You can also cancel by emailing support@nimbuswatch.com.You keep full access until the end of the current billing period, and then your account reverts to Free. You are not charged again after that period ends. There are no prorated refunds for the unused portion of the current billing period.

Yes: a paid plan carries a 7-day money-back guarantee. Dissatisfied customers may request a refund within 7 days of purchase. Claim it through support: email support@nimbuswatch.com and we make the refund by hand. There is no self-service refund button, and nothing is refunded automatically. Outside that, cancelling works as described above, with no prorated refunds for unused time.

You can delete your account yourself from Settings: type your email to confirm, and we remove your monitors, check history, alerts, AWS connections and credentials, scan findings, and your Slack webhook. Billing and invoice records are kept for legal and tax reasons.

No. Sign up with an email and password; a card is only needed when you choose to subscribe to a paid plan.

We cannot email you about a failed payment yet, so your dashboard is where we tell you. Your plan does not stop the moment a charge fails: it stays where it is while the payment is outstanding, and the limits you have paid for keep applying. The card on file has to be replaced by you, and you can do that yourself: use Update your card on your dashboard, which opens Stripe’s secure page and puts the new card on your subscription. If that page will not open, write to support@nimbuswatch.com. If the charge is never collected, Stripe ends the subscription and your account returns to the Free plan: the extra monitors, the faster check schedule and Slack and email alerts stop, and in-app alerts keep working.

Every account gets one personal referral link and code, shown on the Referrals page in the app. Your link and code work for every friend who uses them: each friend who signs up through it gets 25% off their first month, applied automatically at checkout, and you earn 25% of their first-month price as account credit: about $2.25 on Starter, $7.25 on Pro, or $19.75 on Scale.

The moment your friend pays for their first month, the credit appears as Pending on your Referrals page, and becomes issued, usable toward your own bill, once your friend has been a paying customer for 30 days. The hold stops the obvious trick: signing up a friend who takes the discount and cancels a week later.

No, it is account credit, never paid out as cash: it comes off your own NimbusWatch bill. It does not expire, and it is capped at $500.00 total per referrer. Once you have earned that much, further referrals earn nothing more.

We do not pay referral credit when the account signing up uses the same email address as the referrer’s account. We may also void credit for referrals we reasonably believe are self-serving or fraudulent.

Six kinds today: your site went down, it recovered, a check answered slower than the latency limit you set for that monitor, your AWS spend crossed your monthly budget (Starter and up), the spend readings for a connected AWS account stopped arriving (Starter and up), or a scan you switched on found something to fix (the security scan is Starter and up, wasted-spend detection is Pro and up). Alerts are de-duplicated per outage: a four-hour outage produces one "down" alert, not one for every check (sixteen checks on Starter's 15-minute schedule, four on Free's hourly one), and a single "back up" alert when it recovers.

Your in-app alert feed on the dashboard (every plan), and Slack or email (Starter and up). If you have Slack alerts switched on, a scan that finds nothing can be kept out of Slack and email, from Alert settings.

In Alert settings: create a Slack incoming webhook in your workspace. The page walks you through it in about 2 minutes, then paste the URL, save, and click Send a test message. We store the webhook encrypted and show it masked: treat it like a password, because anyone who has it can post into that channel.

Yes, per monitor. Set “alert when slower than X ms” when you add or edit a monitor, and leave it empty to turn that alert off for the monitor.

Yes, on Starter and up. Email alerts go to the address on your account, and there is a switch for them in Alert settings. On the Free plan alerts stay in the in-app feed.