From “just deployed” to fully watched in about 15 minutes

This is the simplest thing NimbusWatch does, and it is the one that saves you the 3 a.m. “is it down?” check. You give us the URL of your app; we fetch it on a schedule and tell you whether it answered, and how long that took.

1. 1. Sign in and open your dashboard.
2. 2. In the Add a monitor panel, give it a Name (“Main app” works perfectly), paste your app’s URL into URL to check, and pick a Check interval.
3. 3. Click Add monitor. The panel says it best: “We check it the moment you save, then on the schedule you pick.”

What you will see: your monitor appears as a row with a status pill: Up in green, Down in red, Pending in grey before the first check lands, plus how fast it answered and a strip of recent checks. There is a Check now button if you want a fresh result on demand.

Now NimbusWatch starts watching your money as well as your website. You connect your AWS account once, and we show your month-to-date spend next to your site checks.

The recommended way is a 1-click read-only role: it deploys a single IAM role in your account that can only read what we need (your spend, and, if you opt in, the security-scan and cost-waste data), can never change anything, and has no access key to create, rotate or remember. There is also an Advanced: a pasted read-only key option if you prefer.

1. 1. On the dashboard, click the Connect AWS account button next to AWS spend.
2. 2. Enter your 12-digit AWS account ID, then open the pre-filled link to deploy one read-only role with CloudFormation. Review the template (it is read-only permissions only), tick the box CloudFormation shows you acknowledging that it is creating an IAM role with a fixed name — that role is the read-only one, and the stack creates nothing else — and create the stack.
3. 3. Come back and click I created the stack, verify & connect. Prefer a key? Choose Advanced: a pasted read-only key instead and follow the key steps there.

What you will see: “We read your spend as soon as you save.” The dashboard’s AWS spend card fills in Month to date, once now and then automatically.

A budget is how you hear about bill creep before it happens, instead of at the end of the month. Pick the number you expect to spend this month; NimbusWatch alerts you the moment your spend crosses it.

1. 1. On the dashboard’s AWS spend card, type a number into Monthly budget in dollars (you can also set it in the same field while connecting the account).
2. 2. Click Save budget. Done.

What you will see: a progress bar on the card (“X% of budget used”, amber as you get close, red when you pass it), plus an End of month (estimate), a rough projection of where the month is heading. The moment spend crosses the budget, an alert appears in your feed. Leave the field empty and save to clear the budget.

Most people who deploy to AWS leave at least one thing open without meaning to: a storage bucket anyone can read, a port open to the whole internet, a login without a second factor. The security scan looks for exactly that, finds each one for you, and tells you the one fix in plain English.

It is opt-in and read-only: nothing runs until you accept the policy, and you accept it once per account. Once accepted, each connected account is scanned about once a day, and the button runs a scan any time you want one. A run you start yourself counts as that account's scan, so the next scheduled pass can find nothing due. You can switch it off at any time by disconnecting the account, or in AWS by deleting the IAM user (pasted key) or the “nimbuswatch-readonly” stack (role).

1. 1. Open the AWS page and find the Security scan section.
2. 2. Read the “What you are allowing, one permission at a time” list, then click I understand, enable the security scan for [your account].
3. 3. Click Run the first scan, and from then on it runs again about once a day on its own. You can run it yourself any time. A run you start yourself counts as that account's scan, so the next scheduled pass can find nothing due. A run reads your storage settings, firewall rules, logins, key ages, databases, audit trail and threat detection. Nothing is changed by it. If a check cannot read one of those, it says so on the page instead of counting as nothing found.

What you will see: either “No issues found” — which means every check finished and found nothing, not that your AWS account is proven safe — or findings with an Urgent / Worth fixing / Info badge, what is wrong in plain English, and a The fix box with the one thing to do. A security finding is a signal to double-check, never a guarantee that nothing else is wrong. Re-run the scan any time you change AWS settings.

This is the scan that finds money quietly draining out of your bill: a server that bills 24/7 while nothing uses it, an IP address nobody attached to anything, disks and backups nothing references, machines far bigger than their traffic needs. Most findings are tied to a dollar figure, an estimate of what that thing costs you each month, and the one thing to do about it, like “delete this unattached disk and save about $12 a month.” A few are advisory, where AWS does not report the data needed to price them. This is the Pro scan: Starter includes the security scan instead, which shows your spend and budget but no cost-waste finding and no estimated saving.

1. 1. On the same AWS page, find the Wasted-spend detection section.
2. 2. Accept its read-only policy, exactly like the security scan.
3. 3. Click Run the first scan, and from then on it runs again about once a day on its own, each finding with its own fix, and a dollar figure where one can be computed. You can run it yourself any time. A run you start yourself counts as that account's scan, so the next scheduled pass can find nothing due.

What you will see: a list of findings, each with a plain-English fix and, wherever AWS reports the data needed to price it, an estimated monthly dollar figure — always tagged as an estimate, since AWS pricing varies. Some checks are advisory and carry no figure rather than a made-up one. Fix the ones that matter, and re-run the scan whenever you like to see the list shrink.

Alerts always land in your in-app feed. Slack or email takes them somewhere you will actually notice: the moment a site stops answering, comes back, answers slowly, your spend passes the budget, or a scan you switched on finds something to fix.

1. 1. Open Alert settings (the Settings button in your dashboard header takes you there). That page has a card for each channel: Slack alerts and Email alerts.
2. 2. If you do not have a webhook yet, the page walks you through How to create a Slack incoming webhook (about 2 minutes). It is a Slack-side setting on your workspace.
3. 3. Paste the webhook into Incoming webhook URL, save it, then click Send a test message.

What you will see: the test message in your Slack channel. From then on your alerts are posted there, apart from any you have chosen to keep out. If a delivery does not go through we retry it a few times, then stop and mark that one alert as failed, and your Slack settings show it — the alert itself stays in your feed either way. Slack and email are switched off if your plan drops back to Free, and in-app alerts keep working. Treat the webhook URL like a password. Anyone who has it can post into that channel, which is why we store it encrypted and show it masked.