Datadog Alternative: What Will the Auditor Ask After You Switch?

The pitch for a Datadog alternative is the bill, and sometimes the region. The question that catches teams out lands six months after the cutover, from an auditor: show me that this alert existed in March, and show me who moved its threshold in April.

March is inside the tool you turned off in February. Who moved the threshold is in a configuration trail that was probably never switched on, and that would have held 90 days of it if it had been.

So here is the position. Residency and cost decide which tool you buy. Evidence decides whether the switch is safe to make, and almost nobody checks it before signing.

Why does a Datadog alternative leave a hole in your evidence?

Because an audit samples a period and a migration cuts across it. A SOC 2 Type II report, an RBI inspection and a customer questionnaire all ask about months rather than about today, and the months before the cutover sit with a vendor you have stopped paying.

The windows are shorter than people assume even when nobody leaves. Datadog's retention table gives metrics 15 months, indexed spans 15 or 30 days "determined by customer plan", and errors 15 days. The trace evidence for an incident in May has gone by July, under contract, with nothing having changed.

Switch, and the new tool starts at zero while the old one stops answering. For a quarter or two you hold two half-records and no single place to point at.

What does an auditor actually ask of an observability tool?

Three things, and only the first two come out as a screenshot. Was there an alert on this control. Did it fire, and what happened next. And who changed it, when, and who approved that.

The third is a record of configuration changes, which is a different product from the monitoring itself. Teams buy the monitoring and assume the record came with it.

The RBI's Cybersecurity, Technology: Risk, Resilience and Assurance Framework Directions, 2026 put this on NBFCs directly. Paragraph 109 requires that every application or system which can access or affect critical or sensitive information "has necessary audit logging capabilities and provides audit trails". Paragraph 110 wants them "sufficiently detailed to facilitate the conduct of audits, serve as forensic evidence when required, and assist in dispute resolution, including for non-repudiation purposes". The thing that decides whether you are told about a failed settlement at 2am is an IT asset by that reading.

How long does your tool remember who changed the alert?

Ninety days at the outside, and only if somebody turned it on.

Datadog's Audit Trail documentation is straight about both halves. "Only users with Audit Trail Write permission can enable or disable Audit Trail", so it is opt-in, and in plenty of organisations nobody has ever had both that permission and a reason to use it. Once enabled, "the default retention period for an audit trail event is 90 days", configurable to 3, 7, 15, 30 or 90. Ninety is the ceiling, not the starting point.

Now hold that against CERT-In's directions of 28 April 2022, which ask for a rolling 180 days of logs maintained within Indian jurisdiction. Whether a vendor's own configuration history falls inside that scope is a question for your counsel rather than for us. The arithmetic is not arguable: the tool holds 90, the direction talks about 180, and the remainder has to live somewhere you control.

What do the directions expect of the vendor's own records?

That you can still get at them. Paragraph 62(2)(i) of the same RBI text, in the outsourcing chapter, requires that "audit trails and logs for administrative activities shall be retained by the service provider and the same shall be accessible to the NBFC based on approved requests".

Read that as a procurement instruction. An observability vendor is a service provider holding administrative logs about your environment, and the clause asks for a route to obtain them. A closed account has no route, no support plan and nobody who has to reply. The rest of what the RBI wants written into a vendor contract is in the post on the outsourcing directions.

The practical version is one line in the exit clause: before the account closes, the vendor exports the change history and the monitor and dashboard definitions in a machine-readable format. Ask while you are still a paying customer and it costs nothing.

Does the alternative keep that record at all?

Sometimes, usually as an add-on, and it is rarely in the comparison table. Check it before the shortlist rather than after.

Grafana's auditing documentation says the feature is available in Grafana Enterprise and Grafana Cloud, that Cloud uses only the Loki exporter, and that to switch it on you "file a support ticket", with "standard ingest and retention rates" applying. It exists, it is billed as log volume, and it is off until you ask. Which units each vendor counts you in is an argument we have already had in full.

A stack you host yourself has nothing of the kind in the product, and that is less of a defeat than it sounds. Alert rules and dashboards in a repository give you reviewers, timestamps and a diff, which is stronger evidence than a vendor's event list. You pay in discipline instead of licence fees.

The cloud provider's own tools earn one warning. CloudTrail covers the API calls, but the services move under you: AWS's September availability update puts Amazon DevOps Guru into sunset with end of support on 30 September 2027. Native is not the same as permanent, which is also where the post on where telemetry actually lands ended up.

What happens to the history you leave behind?

Logs come with you only if the exit was built before anyone needed it. Datadog's Log Archives forward "all the logs ingested, whether indexed or not" to S3, Azure Storage or Google Cloud Storage as compressed JSON. Log Rehydration then reads back "from customer-owned storage-optimized archives", up to a billion events per historical view.

Both sentences point the same way. Nobody is keeping a copy on your behalf, and if no archive was configured, the logs you chose not to index are the ones an incident review will ask for.

Two details worth knowing before you plan around rehydration. A CSV download of a historical view "is limited to the last 90 days", and a rehydration cancelled halfway still bills you, because "all scanned and indexed logs will still be billed". It is metered retrieval, not an archive you browse. Holding the compliance copy inside the tool is the expensive way to do it either way, which the post on cutting a Datadog bill works through line by line.

Metrics have no equivalent. No archive product exists for them, so the 15 months comes out through the API before you go or not at all.

What can you set up on Monday?

An hour, two things, and neither depends on which tool wins.

First, pull the change history out of the vendor and into a file you keep. The audit events API takes a time range. It needs an application key as well as an API key, which is why the first attempt usually returns 403.

curl -s -X POST "https://api.datadoghq.com/api/v2/audit/events/search" \
  -H "DD-API-KEY: $DD_API_KEY" \
  -H "DD-APPLICATION-KEY: $DD_APP_KEY" \
  -H "Content-Type: application/json" \
  -d '{"filter":{"from":"now-90d","to":"now"},"page":{"limit":1000}}' \
  > "audit-$(date +%F).json"

Read the event names in what comes back, add a filter query for the monitor and dashboard ones, then run it weekly from CI. Use your own site host: api.ap1.datadoghq.com for the Tokyo site.

Second, give the file somewhere to land that outlives the contract. S3 Object Lock "works only in buckets that have S3 Versioning enabled", and asking for it at creation turns versioning on for you.

aws s3api create-bucket --bucket acme-observability-evidence \
  --region ap-south-1 \
  --create-bucket-configuration LocationConstraint=ap-south-1 \
  --object-lock-enabled-for-bucket

aws s3api put-object-lock-configuration \
  --bucket acme-observability-evidence \
  --object-lock-configuration \
  '{"ObjectLockEnabled":"Enabled","Rule":{"DefaultRetention":{"Mode":"COMPLIANCE","Days":190}}}'

A hundred and ninety days rather than 180, because the window rolls and its edge should not be a rounding argument. Pick the mode deliberately. In governance mode anyone holding s3:BypassGovernanceRetention can delete the object, and AWS notes the console sends the bypass header by default; in compliance mode nobody can, "including the root user in your AWS account". Evidence belongs in the second one.

Then point the vendor's log archive at the same bucket, and the thing an auditor samples stops being something you rent.

When is switching tools before an audit the wrong call?

When the observation window is already open. Inside a SOC 2 Type II period, or a few weeks out from an inspection, keep the old subscription alive on its smallest plan until the period closes and run the new tool beside it. Two bills for a quarter hurt less than explaining a gap in a control to somebody who has to write a sentence about it.

And if the estate is twenty monitors looked after by two people, an exported change history is ceremony. The git log of the repository that defines them is the evidence, and it is better than anything a vendor would have handed over.

The short version

Three things this week, before anyone shortlists a tool. Enable the audit trail and set it to 90 days. Schedule a weekly export of it into a bucket in your own account with Object Lock on. Configure the log archive so the compliance copy is yours.

Then ask every candidate the two questions that are not on the comparison sheet: does it record who changed an alert, and for how long. A tool that cannot answer either is not cheaper. It has moved the cost to the week you are being audited.

What a switch costs in rebuilt monitors and dashboards is a separate number, and the one most quotes leave out. We counted it in the post on what you would have to rebuild.

This is engineering guidance, not legal advice. Regulations and their annexures are amended over time; read the current text and take your compliance position from counsel.